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ABSTRACT 

This  document  compiles  the  existing  NIU-Forum  agreements  for  an  ISDN  developed  and  approved  in  the  NIU- 
Forum  as  of  October  1991.  These  agreements  cover:  Layer  1  BRI  at  the  U,  and  S/T  reference  points;  Layer  1 
PRI  at  the  U/S/T  reference  points;  Layer  2  BRI  and  PRI;  Layer  3  BRI  Basic  Call  Control  for  Class  I  equipment; 
Layer  3  PRI  Basic  Call  Control  for  Class  II  equipment;  and  Generic  Control  procedures  for  Class  I  BRI 
Supplementary  Services.  In  addition,  this  document  references  the  Conformance  tests  which  have  been 
completed  by  the  NIU-Forum.  These  include:  Layer  1  BRI  S/T  interface;  and  Layer  2  BRI  LAPD.  Finally,  this 
document  contains  the  Application  Profiles  for:  four  of  the  Incoming  Call  Management  applications;  the 
Building  Controls  appUcation;  the  Data  Conferencing  -  Point-to-Point  application;  the  ISDN  Station  Event 
Recording  application;  and  tlaree  of  the  Voice  Messaging  System  applications  which  have  been  submitted  to  the 
NIU-Forum. 
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NOTICE  OF  DISCLAIMER 

I 
I 
I 
I 

This  document  compiles  NIU-Forum  voluntary  agreements  among  participating  expert  technical  \ 

personnel  to  the  texts  of  isdn  standards,  configurations  and  descriptions  that  are  intended  to 

promote  interoperability  and  efficiency.  these  agreements  were  developed  and  approved  by 

organizations  participating  in  the  north  american  isdn  users'  forum  (niuf)  meetings  as  of 

October  1991.  In  the  October  1991  meeting,  participants  in  the  NIUF  Plenary  agreed  to  publish  j 

ALL  AGREEMENTS  APPROVED  AS  OF  THAT  MEETING.  NEITHER  THE  NATIONAL  INSTITUTE  OF  STANDARDS  AND  j 

Technology  nor  any  of  the  participants  in  the  NIUF  make  any  representation  or  warranty, 

EXPRESS  OR  implied  WITH  RESPECT  TO  THE  SUFFICIENCY,  ACCURACY,  OR  USE  OF  ANY  INFORMATION  OR  OPINION 
CONTAINED  HEREIN.   THE  USE  OF  THIS  INFORMATION  OR  OPINION  IS  AT  THE  RISK  OF  THE  USER.   UNDER  NO 
CIRCUMSTANCES  SHALL  NIST,  OR  ANY  PARTICIPANT  IN  THE  NIUF  BE  LIABLE  FOR  ANY  DAMAGE  OR  INJURY 
INCURRED  BY  ANY  PERSON  ARISING  OUT  OF  THE  SUFFICIENCY,  ACCURACY,  OR  USE  OF  ANY  INFORMATION  OR 
OPINION  CONTAINED  HEREIN. 

NIST  does  not  recommend  or  endorse  products  and  nothing  contained  herein  is  intended  as  a  recommendation  or 
endorsement  of  any  product. 
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1  Introduction 

The  purpose  of  the  Integrated  Services  Digital  Network  (ISDN)  Agreements  document,  its 
organization  and  an  overview  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  are 
described  in  the  following  subsections. 

1.1  Purpose  of  this  Document 

Participants  in  the  October  1991  NIU-Forum  Plenary  meeting,  approved  a  motion  to  publish  all 
agreements  reached  among  the  members  as  of  October  1991.  This  document  is  a  compilation  of 
these  NIU-Forum  agreements  for  an  ISDN. 

1.2  Evolution  of  this  Document 

New  versions  of  this  document  will  be  issued  as  progress  is  made  in  developing  and  approving 
implementation  agreements,  conformance  tests,  and  application  profiles  within  the  NIU-Forum. 
It  is  the  intent  of  the  NIU-Forum,  that  each  new  version  be  compatible  with  previous  versions. 
Therefore,  each  revision  will  supersede  preceding  versions,  as  each  new  version  will  include  all 
of  the  unchanged  agreements  from  previous  versions,  as  well  as  errata  pages  for  previously 
approved  agreements. 

1.3  Document  Organization 

The  ISDN  Agreements  document  is  organized  into  specific  sections  as  follows: 

•  Section  1 

Introduction  —  The  purpose  of  this  document,  the  document  organization,  and  an 
overview  of  the  structure  and  organization  of  the  NIU-Forum. 

•  Section  2 

ISDN  Versions  —  A  specific  interoperable  subset  of  an  ISDN  which  functions  in  a  multi- 
vendor  environment. 

•  Section  3 

Implementation  Configurations  —  A  categorization  of  the  ISDN  capabilities,  based  upon 
access  and  equipment  class  information. 

•  Section  4 

Implementation  Agreements  —  The  Implementation  Agreements  (lAs)  are  developed  by 
both  implementor  and  user  representatives  participating  in  the  NIU-Forum  Expert  Working 
Groups.  The  lAs  provided  in  this  section  allow  for  expeditious  development  of  ISDN 
capabilities,  and  promote  interoperability  of  ISDN  communications  equipments. 

•  Section  5 

ISDN  Conformance  Test  Specifications  —  Conformance  Test  (CT)  suites  for  an  ISDN 
aie  detailed  in  this  section  of  the  agreements. 
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•  Section  6 

Application  Software  Interface  —  The  Application  Software  Interface  (ASI)  section  will 
focus  on  the  definition  of  a  common  application  interface  for  accessing  and  administering 
ISDN  services  provided  by  Network  Adapters. 

•  Section  7 

Application  Profiles  —  The  Application  Profiles  (APs)  contain  the  recommended  set  of 
agreements  and  specifications  for  all  layers  and  aspects  of  ISDN  communication  which 
must  be  present  to  support  a  particular  user's  application  or  set  of  applications  (application 
family). 

•  Section  8 

References  —  The  References  section  provides  a  listing  of  documents  identified  but  not 
included  in  this  publication. 

1.4  NIU-Forum  Overview 

The  following  text  introduces  the  NIU-Forum  purpose  and  organization. 

1.4.1  Purpose  of  the  Forum 

The  Integrated  Services  Digital  Network  (ISDN)  is  defined  in  a  group  of  international 
recommendations  for  a  worldwide  communications  network  for  the  exchange  of  all  information 
(voice,  data,  and  image)  among  all  users,  independent  of  any  manufacturer,  service  provider,  or 
implementation  technology. 

ISDN  recommendations  are  being  developed  by  the  International  Telephone  and  Telegraph 
Consultative  Committee  (CCITT).  In  North  America,  the  ISDN  standards  are  being  developed  by 
Committee  Tl,  which  is  accredited  by  the  American  National  Standards  Institute  (ANSI)  and 
sponsored  by  the  Exchange  Carriers  Standards  Association  (ECSA). 

The  result  is  one  extensive  standard  with  a  tremendous  variety  of  options  and  parameters.  This 
-is  necessary  to  meet  all  the  possible  needs  and  technologies  for  which  the  standards  could  be  used. 
However,  to  ensure  interoperability  and  terminal  portability  within  the  ISDN  network  and  its 
attendant  terminals  and  other  Customer  Premises  Equipment  (CPE),  a  uniform  subset  of  these 
options  and  parameters  must  be  selected.  Each  apphcation  usually  only  requires  a  subset  of 
functionality  and  in  order  for  products  to  work  together  in  a  multi-vendor  environment,  common 
sets  of  options  must  be  selected. 

To  cope  with  this  proliferation  of  choices  and  to  provide  practical  products  and  services  which 
meet  users'  needs,  the  specification  process  must  be  extended  to  include  Application  Profiles, 
Implementation  Agreements,  and  Conformance  tests  to  promote  interoperability. 

1.4.2  NIU-Forum/NIST  Relationship 

The  North  American  ISDN  Users'  Forum  has  created  a  user  voice  in  the  implementation  of  ISDN 
and  ISDN  applications  and  has  helped  to  ensure  that  the  emerging  ISDN  environment  meets  users' 
application  needs.  The  NIU-Forum  is  sponsored  by  the  National  Institute  of  Standards  and 
Technology  (NIST).    The  precise  relationship  of  the  NIU-Forum,  NIST,  and  other  business 
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concerns  is  defined  by  the  "Cooperative  Research  and  Development  Agreement:  The  Consortium 
on  ISDN  Based  Systems."' 

1.4.3  NIU-Forum  Organization  and  Procedures 

The  actual  work  of  the  NIU-Forum  is  accomplished  in  two  workshops;  the  ISDN  Users'  Workshop 
(lUW)  and  the  ISDN  Implementors'  Workshop  (IIW).  These  workshops,  which  consist  of  various 
working  groups  and  special  project  teams,  meet  several  times  a  year  and  develop  the  following 
products:  Application  Requirements,  Application  Analyses,  Application  Profiles,  Implementation 
Agreements,  Conformance  Criteria,  and  an  Applications  Software  Interface.  The  lUW  produces 
Application  Requirements  which  describe  potential  apphcations  of  ISDN  and  the  features  which 
may  be  required. 

The  IIW  develops  Application  Analyses,  Application  Profiles,  Implementation  Agreements, 
Conformance  Criteria,  and  an  Applications  Software  Interface  which  provide  the  technical  detail 
necessary  to  implement  an  Application  Requirement  in  an  interoperable  manner. 

The  activities  within  the  two  workshops  are  coordinated  by  the  NIU-Forum  Executive  Steering 
Committee.  While  specifics  of  the  NIU-Forum  organization  follow,  particulars  relating  to  the 
procedures  for  the  NIU-Forum  are  found  in  the  "North  American  ISDN  Users'  Forum  Practices 
Manual."^ 

1.4.3.1  ISDN  Users'  Workshop  (lUW) 

The  lUW  is  responsible  for  identifying,  defining,  and  prioritizing  user  requirements,  as  well  as 
working  with  the  IIW  to  define  and  approve  agreements  necessary  to  support  the  implementation 
of  user  requirements.  Membership  in  the  lUW  is  open  to  any  organization.  Users  participating 
in  the  IlAV  are  organized  into  seven  Industry  Groups:  Manufacturing  Industries,  Process 
Industries,  Service  Industries,  Small  Business,  Financial  Services,  Government,  and  Computing  and 
Telecommunications  Industries.  The  lUW  organization  emphasizes  the  synergy  present  when 
organizations  from  the  same  industry  segment  work  together  to  define  applications.  Activities 
within  the  lUW  are  coordinated  by  the  lUW  Steering  Committee. 

The  lUW  work  program  is  based  on  identifying  potential  user  applications  and  structuring  the  IIW 
work  to  satisfy  the  user  applications.  Any  user  can  request  consideration  for  a  particular  ISDN 
application.  The  request  should  be  for  an  application  which  could  be  used  to  support  business 
related  operations.  It  is  important  that  ISDN  solutions  to  business  problems  be  based  on  business 
considerations  which  include: 

•  cost  reductions 

•  prcxluctivity  enhancements 

•  standard  application  interfaces 

•  and  performance  improvements. 


'For  more  information,  contact  the  NIU-Forum  Administrator  (see  sec.  1.5). 
^Ibid. 
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For  a  detailed  description  of  the  "User  Application"  Processing  within  the  ISDN  Users'  Workshop, 
please  refer  to  "North  American  ISDN  Users'  Forum  Practices  Manual."^ 

1.4.3.2  ISDN  Implementors'  Workshop  (HW) 

The  nw  is  responsible  for  developing  Application  Analyses,  Application  Profiles,  Implementation 
Agreements,  Conformance  Criteria,  and  an  Applications  Software  Interface  in  support  of  lUW 
defined  Application  Requirements.  The  IIW  also  provides  technical  advice  and  consul tafion  to  the 
lUW,  sponsors  multi-vendor  demonstrations  and  trials,  and  provides  formal  liaisons  with 
appropriate  organizations  such  as  the  Corporation  for  Open  Systems  (COS),  the  Open  Systems 
Interconnection  (OSI)  Implementors'  Workshop  (OIW),  or  the  ANSI  Accredited  Standards 
Committee  Tl.  Membership  in  the  IIW  is  open  to  any  organization. 

The  IIW  Steering  Committee  is  responsible  for  coordinating  the  activities  of  the  IIW  groups.  The 
IIW  is  organized  into  the  following  groups: 

•  Applications  Analysis  Working  Group  (WG) 

•  Application  Profile  Teams 

•  Expert  WGs 

•  ISDN  Conformance  Test  aCOT)  WG. 

The  Applications  Analysis  WG  develops  an  analysis  of  the  user's  application  requirements,  which 
serves  as  a  basis  for  development  of  the  Application  Profile  by  the  Applications  Profile  Teams. 
The  Expert  WGs  produce  the  Implementation  Agreements  that  are  generally  based  on  ANSI 
standards.  In  addition,  there  is  an  Expert  WG  defining  an  Applications  Software  Interface.  The 
ICOT  WG  defines  conformance  requirements  and  develops  abstract  test  suites  for  Implementation 
Agreements  and  Application  Profiles. 

1.4.4  ISDN  Versions 

A  version  defines  and  specifies  ISDN  as  it  exists  at  a  certain  point  in  time  as  derived  from  existing 
national  and  international  standards  and  other  consensus  activities.    Each  version  should  be 
-Completely  compatible  with  earlier  versions.    Manufacturers  and  service  providers  would  be 
expected  to  develop  ISDN  offerings  based  on  a  particular  version. 

1.5  Point  of  Contact 

Further  information  about  the  NIU-Forum,  including  information  on  specific  groups  or  activities 
within  the  NIU-Forum  can  be  obtained  by  contacting: 

NIU-Forum  Secretariat 

National  Institute  of  Standards  and  Technology 
Building  223,  Room  B364 
Gaithersburg,  Maryland  20899 
(301)  975-2937 


^Ibid. 
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2  Future  ISDN  Versions 


Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  definition  and  specification 
of  ISDN  Versions. 
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3  Implementation  Conflgurations 


The  ISDN  architecture  is  intended  to  interconnect  all  user  and  network  equipments,  in  a  ubiquitous 
fashion,  to  provide  a  common  network  encompassing  all  possible  conmiunication  scenarios. 
Because  of  this  broad  scope,  the  national  standards  for  the  ISDN  could  not  be  universally  applied 
to  all  the  conceivable  combinations  of  equipment  types,  access  arrangements  and  applications.  The 
concept  of  implementation  configurations  is  introduced  to  allow  specific  ISDN  capabilities 
(procedures)  to  be  associated  with  a  class  of  equipment,  an  access  arrangement,  or  an  application. 

The  use  of  the  equipment  class/access  arrangement  terminology  permits  clarification  of  the 
circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability 
applies  only  to  a  subset  of  four  possible  configurations. 

The  implementation  configurations,  which  were  defined  by  the  NIU-Forum  Signalling  Working 
Group  (SWG),  have  been  applied  to  tlie  layer  3  circuit-switched  signalling  protocols  only.  Future 
work  will  evaluate  the  implementation  configuration  concept  for  applicability  to  all  agreements 
emerging  from  the  NIU-Forum. 

The  following  text  provides  the  current  description  of  implementation  configurations  from  the 
SWG: 

The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit  certain  procedures  to 
be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
Private  Branch  Exchange  (PBX).  Specifically,  two  classes  of  equipment  are  defined  on  the  basis 
of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  pubhc 
network's  point  of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the 
public  network  and  ISDN  terminals  or  telephones  connected  to  that  equipment).  For  example, 
some  user  equipment  may  support  subtending  Basic  Access  digital  subscriber  loops  and/or  analog 
telephone  loops.  For  Class  I  equipment,  the  network  makes  no  provision  for  such  an  arrangement 
and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication.  Conversely, 
in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that 
communication  between  Class  II  equipment  (with  which  it  communicates  directly)  and  other 
equipment  (with  which  the  network  does  not  have  direct  contact)  may  occur.  As  an  example.  Class 
II  equipment  may  support  digital  and/or  analog  subscriber  loops.  Use  of  Class  11  equipment  also 
involves  the  possibility  of  having  interworking  occur  beyond  the  equipment  with  which  the  network 
has  direct  contact.  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network  with 
an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called 
party  respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking 
notification,  if  a  private  network  exists  beyond  the  Class  II  equipment  and  interworking  to  a  non- 
ISDN  facility  within  that  network  takes  place.  When  an  interface  is  associated  with  Class  I 
equipment,  it  is  assumed  that  multiple  pieces  of  equipment  may  exist  and  communicate  with  the 
network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN-capable 
and  is  considered  as  the  endpoint  of  tlie  communication.  Therefore,  interworking  notification 
should  not  be  accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  tiie  manner  in  which  a  SETUP  message,  the  message  which  initiates 
an  ISDN  call,  should  be  presented  to  the  user  equipment.  When  Class  I  equipment  is  applied  on 
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a  particular  interface,  the  network  should  broadcast  the  SETUP  message  associated  with  each  call 
that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces  of  user 
equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP 
messages  associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being 
used.  Here,  a  single  piece  of  user  equipment  is  assumed  to  be  involved  in  all  communication  with 
the  network. 

To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply 
to  all  ISDN  user  configurations.  However,  in  cases  for  which  integrated  procedures  are  not 
appropriate,  the  call  control  procedures  associated  with  Equipment  Class  I  will  differ  from  those 
associated  with  Equipment  Class  II.  Unless  otherwise  noted,  the  assumption  should  be  that  a 
particular  procedure/capability  should  be  provided  for  both  classes  of  equipment  on  both  basic  and 
primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits  clarification  of  the 
circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capabihty 
applies  only  to  a  subset  of  four  possible  configurations  which  are  labeled  as  follows. 

Table  3-1.  Implementation  Configurations 


Class  I 


Class  n 


BRI 
PRI 


IB 

IIB 

IP 

IIP 

BRI:  Basic  Rate  Interface 
PRI:  Primary  Rate  Interface 


In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access 
interfaces  {IB)  and/or  primary  rate  access  interfaces  {IP).  Similarly,  a  capability  that  applies  to 
-  Class  II  equipment  may  be  provided  on  basic  access  interfaces  {IIB)  and/or  primary  rate  access 
interfaces  {IIP). 

The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate 
when  protocol  or  procedures  are  only  expected  to  be  supported  for  a  particular  class  and/or  are 
limited  to  a  particular  type  of  interface,  i.e.,  basic  or  primary  rate  interface. 
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4  Implementation  Agreements 

The  Implementation  Agreements  (lAs)  generated  by  the  NIU-Forum  IIW  provide  the  agreements 
for  implementing  the  American  National  Standard  (ANS)  specifications  for  an  ISDN.  These  lAs 
were  developed  and  approved  by  both  industry  and  user  representatives  participating  in  the  Expert 
Working  Groups,  as  well  as  the  NIU-Forum  Plenary.  The  lAs  exist  to  expedite  the  development 
of  ISDN  capabilities,  to  promote  interoperability  of  ISDN  communications  equipments,  and  to 
provide  a  universal,  multi-vendor  implementation.  The  following  text  details  the  lAs.'' 

4.1  ISDN  Lower  Layer  Specifications 

The  ISDN  lower  layer  specifications  define  the  layer  1,  2,  and  3  requirements  of  an  ISDN. 
Network  signalling,  via  the  D-channel,  is  the  focus  of  these  agreements  but,  where  appropriate, 
user  data  specifications  of  layers  1,  2,  and  3  have  been  included.  These  I  As  were  developed  in 
the  Signalling  Expert  Working  Group  (SWG)  of  the  IIW.  These  I  As  provide  a  framework  and  a 
set  of  protocol  procedures  for  accessing  an  ISDN,  so  that  systems  implemented  according  to  these 
agreements  can  successfully  interoperate.  The  following  text  details  the  ISDN  lower  layer  lAs. 

4.1.1  Layer  1  Basic  Rate  Interface  (BRI) 

The  ISDN  Basic  Rate  Interface  (BRI)  physical  layer  specifications  are  defined  for  their  specific 
reference  point  of  application.  These  reference  points  are  S,  T  and  U,  providing  the  user  and 
network  interfaces  for  Terminal  Equipment  (TE)  and  Network  Termination  (NT)  equipments.  The 
following  lAs  are  defined  for  the  BRI  physical  layer. 

4.1.1.1  U  Reference  Point 

The  I A  Basic  Access  Interface  for  Use  on  Metallic  Loops  for  Application  on  the  Network  Side  of 
the  NT  —  Layer  1  Specification  (NIU  89-101)  states:  "The  physical  layer  of  the  Basic  Access 
Interface  at  the  U  reference  point  is  specified  in  ANS  Tl. 601-1988,  Integrated  Services  Digital 
Network  —  Basic  Access  Interface  for  Use  on  Metallic  Loops  for  Application  on  the  Network  Side 
of  the  NT  —  Layer  I  Specification,  (Ref.  [12]). 

This  lA  adopts  ANS  T1.601-I988  (Ref  [12])  without  exception." 

4.1.1.2  S  and  T  Reference  Points 

The  lA  Basic  Access  Interface  at  S  and  T Reference  Points  —  Layer  1  Specification,  (NIU  89-105) 
states:  "The  physical  layer  of  the  Basic  Access  Interface  at  the  S  and  T  reference  points  is 
specified  in  ANS  Tl. 605-1989,  Integrated  Services  Digital  Network  —  Basic  Access  Interface  at 
S  and  T  Reference  Points  —  Layer  I  Specification,  (Ref  [16]). 

This  lA  adopts  ANS  Tl. 605-1989  (Ref  [16])  without  exception." 


"The  NIU-Forum  Plenary  document  numbers  (e.g.,  NIU  89-101)  are  included  for  reference  purposes 
only,  as  every  numbered  implementation  agreement  is  included  in  the  present  document  in  its  entirety. 
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4.1.2  Layer  1  Primary  Rate  Interface  (PRI) 

The  ISDN  Primary  Rate  Interface  (PRI)  physical  layer  specifications  are  defined  for  the  S,  T,  and 
U  reference  points.  These  reference  points  provide  the  user  and  network  interfaces  for  TE  and  NT 
equipments.  The  following  lA  is  defined  for  the  PRI  physical  layer. 

4.1.2.1  S,  T,  and  U  Reference  Points 

The  lA  Primary  Rate  Customer  Installation  Metallic  Interfaces,  Layer  1  Specification  (NIU  89- 
103R1)  states:  "The  physical  layer  of  the  Primary  Access  Interface  is  specified  by  ANS  T 1.408- 
1990,  ISDN  Primary  Rate  —  Customer  Installation  Metallic  Interfaces,  Layer  1  Specification,  (Ref. 
[11]). 

This  lA  applies  to  the  Primary  Rate  S,  T,  and  U  reference  points. 
This  lA  adopts  ANS  Tl. 408-1990  (Ref  [11])  without  exception." 

NOTE:  Previous  revisions  of  this  lA  were  based  upon  the  ANS  Tl.403-1989  (Ref  [10]),  (the  DSl 
specification)  and  can  be  found  in  NIST  Special  Publication  500-195,  North  American  ISDN  Users 
Forum  Agreements  on  ISDN  (Ref  [51]). 

4.1.3  Layer  2  BRI  and  PRI 

The  ISDN  Basic  Rate  Interface  (BRI)  and  Primary  Rate  Interface  (PRI)  access  arrangements 
specifies  one  common  lA  for  the  D-channel  layer  2  data  link. 

The  lA  Data  Link  Layer  Signalling  Specification  for  Application  at  the  User-Network  Interface 
(NIU  89-210)  states:  "The  data  link  layer  of  the  D-channel  is  specified  in  ANS  Tl.602-1989, 
ISDN  Data  Link  Layer  Signalling  Specification  for  Application  at  the  User-Network  Interface,  (Ref 
[13]). 

This  lA  adopts  ANS  Tl.602-1989  (Ref  [13])  with  the  following,  additional  clarifications: 

1)  Both  automatic  and  non-automatic  Terminal  Endpoint  Identifier  (TEI)  assignment  terminals 
shall  be  allowed  to  connect  to  a  passive  bus.  Automatic  TEI  assignments  are  preferred,  since  it 
would  be  the  responsibility  of  the  user  to  ensure  that  different  TEIs  are  used  by  each  different 
terminal  for  non-automatic  TEI  allocation  equipment. 

2)  It  is  recommended  that  the  data  link  monitor  function  be  operated  on  at  least  one  link 
associated  with  each  TEI." 

4.1.4  Layer  3  BRI  and  PRI 

The  ISDN  BRI  and  PRI  access  arrangements  will  utilize  the  layer  3  Signalling  protocol  as  defined 
by  ANS  Tl.607-1990,  ANS  Tl.608-1990  and  ANS  Tl.610-1990  (Refs.  [17,  18,  20]).  These 
specifications  apply  to  two  distinct  connection  types:  circuit-switched  and  packet-switched.  The 
following  text  details  the  lAs  for  ISDN  layer  3  signalling. 
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4.1.4.1  Circuit-Switched  Call  Control  Procedures 

The  circuit-switched  layer  3  signalling  protocol  shall  be  responsible  for  the  establishment, 
maintenance  and  tear-down  of  basic  signalling  connections  and  supplementary  service  signalling 
connections  which  utilize  circuit-switched  access.  The  following  text  details  the  circuit-switched 
call  control  procedures. 

4.1.4.1.1  Basic  Call  Control  Procedures 

The  lAs  (NIU  300  Series)  for  the  ISDN  Basic  Call  Control  procedures  state:  the  circuit-switched 
network  layer  protocol  is  specified  in  the  ANS  Tl. 607- 1990,  Digital  Subscriber  Signalling  System 
No.  1  (DSSl)  —  ISDN  Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref. 
[17]). 

The  lAs  have  adopted  ANS  Tl  .607-1990  (Ref.  [17]),  according  to  the  implementation 
configuradons,  as  follows: 

•  Class  I  BRI  {IB) 

The  Class  I  BRI  {IB)  basic  call  control  signalling  lA  Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for  the  ISDN  Basic  Rate  Interface/Class  I  is 
included  in  Appendix  A. 

•  Future  Class  I  PRI  {IP) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Class  I  PRI  {IP)  basic  call  control 
signalling. 

•  Future  Class  II  BRI  {IIB) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Class  II  BRI  {IIB)  basic  call 
control  signalling. 

•  Class  11  PRI  {IIP) 

The  Class  II  PRI  {UP)  basic  call  control  signalling  lA  Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for  the  ISDN  Primary  Rate  Interface/Class  II  is 
included  in  Appendix  B. 

4.1.4.1.2  Supplementary  Services  Control  Procedures 

The  lAs  (NIU  310  Series)  for  the  ISDN  Supplementary  Services  Control  procedures  are  based 
upon  ANS  Tl  .610-1990,  Digital  Subscriber  Signalling  System  No.  I  (DSSI )  —  Generic  Procedures 
for  the  Control  of  ISDN  Supplementary  Services,  (Ref.  [20]).  The  following  text  details  the  lAs. 

•  Class  I  BRI  {IB) 

The  lA  (NIU  89-311  )  for  the  Class  I  BRI  {IB)  Supplementary  Services  Control  procedures  states: 
The  generic  procedures  for  the  control  of  ISDN  Supplementary  Services  for  Class  I  equipment  on 
a  Basic  Rate  Interface  (BRI)  is  specified  in  ANS  Tl  .610-1990  (Ref.  [20]). 


NIU-Forum  Agreements  On  ISDN 


4-3 


The  following  changes  shall  apply  to  the  ANS  Tl. 610-1990  (Ref.  [20])  specification: 


1.  In  section  4,  the  Keypad  protocol  only  applies  during  the  establishment  phase  of  a  call; 

2.  In  section  5.2.2.1,  the  option  of  using  the  dummy  call  reference  for  sending  a  call- 
associated  feature  request  is  removed. 

3.  In  section  2.1.3,  section  6,  and  Appendix  I,  the  Common  Information  Element  Category 
of  the  Functional  Protocol  is  removed; 

4.  In  section  7,  the  FACILITY  and  REGISTER  messages  are  removed; 

5.  In  section  8,  the  Facility  information  element  is  removed; 

6.  In  Annex  A,  the  Terminal  Identification  procedures  for  assignment  of  USID  and  TED  at 
subscription  time  are  removed; 

7.  In  Annex  B,  section  2.1,  the  words  "in  the  Called  party  number  information  element  in 
one  or  more  INFORMATION  messages"  should  be  changed  to  "in  the  Called  party 
number  information  element  in  one  INFORMATION  message"; 

8.  Remove  Appendix  III  General  Description  of  Component  Encoding  Rules. 

9.  The  scope  of  this  implementation  agreements  is  applicable  only  to  the  ISDN  Basic  Access 
Rate  as  applied  to  Class  I  equipment. 

•  Future  Class  I  PRI  (IP) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Class  I  PRI  (IP)  Supplementary 
Services  Control  procedures. 

•  Future  Class  II  BRI  (7/5) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Class  II  BRI  (7/5)  Supplementary 
Services  Control  procedures. 

•  Future  Class  II  PRI  (77P) 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Class  II  PRI  (IIP)  Supplementary 
Services  Control  procedures. 

4.1.4.2  Packet-Switched  Call  Control  Procedures 

The  Lower  Layer  Special  Interest  Group  (LLSIG),  of  the  OIW,  has  the  responsibility  of  developing 
the  lAs  for  packet-switched  Connections.  Their  work  overlaps  with  the  packet-switched  services 
provided  by  an  ISDN.  Therefore,  the  SWG  has  the  responsibility  to  review  the  LLSIG' s  lAs  and 
provide  to  the  LLSIG  any  additional  information/clarification  necessary  to  ahgn  these  lAs  with 
those  defining  the  ISDN. 

The  packet-switched  layer  3  signalling  protocol  shall  be  responsible  for  the  establishment, 
maintenance  and  tear-down  of  basic  signalling  connections  and  supplementary  service  signalling 
connections  which  utilize  packet-switched  access.  The  following  text  details  the  packet-switched 
call  control  procedures. 
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The  lA  (NIU  89-320)  for  the  ISDN  Basic  Call  Control  procedures  states:  the  packet-switched 
network  layer  protocol  is  specified  in  the  CCITT  Recommendation  Q.93 1-1988  (also  designated 
CCITT  Reconunendation  1.451-1988),  ISDN  User-Network  Interface  Layer  3  Specification,^  (Ref. 
[26]). 

The  following  agreements  have  been  reached  concerning  the  use  of  CCITT  Recommendation 
Q.931-1988,  (Ref.  [26]): 

1.  On  a  BRI  supporting  the  ISDN  virtual  circuit  service,  all  of  CCITT  Recormnendation  Q.931- 
1988  (Ref.  [26])  section  6,  except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched 
access  case),  shall  apply.  The  following  sections  also  apply;  3.2  (messages  for  packet-mode  access 
connection  control),  4-4.5  (section  specifying  general  information  element  handling  and  encoding), 
4.7  (information  elements  for  packet  communications). 

2.  On  a  PRI  supporting  the  ISDN  virtual  circuit  service  all  of  Q.931-1988  (Ref.  [26])  section  6, 
except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched  access  case),  6.1.2.2,  6.2.2.2 
and  6.4.2  (the  sections  specifying  the  D-channel  ISDN  virtual  circuit  service  case),  shall  apply. 
The  following  sections  also  apply:  2.2  (packet-mode  access  connection  states),  3.2  (messages  for 
packet-mode  access  connection  control),  4-4.5  (section  specifying  general  information  element 
handling  and  encoding),  4.7  (information  elements  for  packet  communications). 

3.  On  a  BRI  or  PRI  supporting  the  Unrestricted  64  kbit/s  circuit-mode  service,  CCITT 
Recommendation  Q.931-1988  (Ref.  [26])  sections  6.1.1,  6.2.1,  6.4.1  and  6.4.3  shall  apply.  The 
following  sections  also  apply:  2.1  (circuit-mode  connection  states),  3.1  (messages  for  circuit-mode 
connection  control),  4-4.5  (section  specifying  general  information  element  handling  and  encoding). 

4.2  Future  Basic  Bearer  Services  Specification 

The  ISDN  basic  bearer  services  specifications  define  the  minimal  set  of  bearer  services  provided 
by  an  ISDN.  The  specifications  outline  the  set  of  essential  bearer  services,  and  their  attributes,  to 
be  provided  by  an  ISDN.  The  lAs  developed  for  the  bearer  services  will  provide  a  specification 
outlining  the  required  bearer  services  and  their  respective  characteristics.  The  following  text  will 
detail  the  ISDN  basic  bearer  services  lAs. 

4.2.1  Future  Minimal  Set  of  BRI  Services 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  minimal  set  of  ISDN  Basic 
Rate  Interface  (BRI)  bearer  services  (Refs.  [15],  [30,  31]). 

4.2.2  Future  Minimal  Set  of  PRI  Services 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  minimal  set  of  ISDN  Primary 
Rate  Interface  (PRI)  bearer  services  (Refs.  [14],  [30,  31]). 


'This  lA  will  be  aligned  with  ANS  Tl. 608-1990,  Digital  Subscriber  Signalling  System  No.  I  (DSSI) 
—  Signalling  Specification  for  X.25  Packet  Switched  Bearer  Service  (Ref.  [18])  when  ANS  Tl.608-1990 
is  stable.  Please  refer  to  section  4.1.4.2  of  the  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working 
Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  I  (Ref.  [32])  for  more 
information  on  this  alignment. 
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4.3  Future  Supplementary  Services  Specification 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  ISDN  supplementary  services 
specifications  (Ref.  [20]). 

4.4  ISDN  Terminal  Adaptation  Specification 

The  ISDN  Terminal  Adaptation  specifications  define  the  requirements  for  attaching  a  non-ISDN 
terminal  to  an  ISDN.  This  attachment  is  performed  across  the  R  reference  point,  with  the 
specification  of  the  R  reference  point  providing  the  necessary  characteristics,  attributes  and 
functions  such  that  successful  interoperabiUty  between  the  non-ISDN  and  the  ISDN  is  achieved. 
The  lAs  developed  for  terminal  adaptation  provide  a  specification  of  the  R  reference  point 
requirements.  The  following  text  details  the  ISDN  terminal  adaptation  lAs. 

4.4.1  Future  Circuit-Mode  Data  Terminal  Adaptation 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  circuit-mode  data  terminal 
adaptation  which  will  define  the  R  reference  point  requirements  when  circuit-switched  connections 
are  provided  by  an  ISDN. 

4.4.2  Packet-Mode  Data  Terminal  Adaptation 

The  packet-mode  data  terminal  adaptation  lAs  define  the  aspects  of  the  packet-mode  services  to 
be  used  by  the  packet-mode  Data  Terminating  Equipment  (DTE),  the  access  requirements,  and  the 
functions  of  the  Terminal  Adapter  provided  across  the  R  reference  point.  These  lAs  were 
developed  in  the  LLSIG  of  the  OSI  Implementors'  Workshop.  Refer  to  the  NIST  OSI 
Implementors'  Workshop  Stable  Implementation  Agreements  for  OSI  Protocols  (Ref.  [52]),  section 
7. 

4.5  ISDN  Management  Specification 

The  ISDN  Management  specifications  provide  the  operations  and  maintenance  requirements  for  the 
various  access  interfaces  and  protocol  levels  of  the  ISDN.  The  lAs  are  to  be  developed  in  the 
Network  Management  Expert  Working  Group  (NMWG)  of  the  IIW.  The  following  text  details  the 
ISDN  Management  lAs. 

4.5.1  Future  Layer  1  BRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  layer  1  ISDN  management 
specification,  for  a  Basic  Rate  Interface  (BRI)  (Ref.  [7]). 

4.5.2  Future  Layer  1  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  layer  1  ISDN  management 
specification,  for  a  Primary  Rate  Interface  (PRI)  (Ref.  [8]). 

4.5.3  Future  Layer  2  and  3,  BRI  and  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  layer  2  and  3  ISDN  management 
specification,  for  a  Basic  Rate  Interface  (BRI)  and  a  Primary  Rate  Interface  (PRI)  (Ref.  [9]). 
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4.6  Future  Common  Channel  Signalling  —  Signalling  System  #7 

Editor's  Note:  Tliis  section  is  reserved  for  future  agreements  on  common  channel  signalling 
system,  ANSI  Signalling  System  #7  (Refs.  [1,  2,  3,  4,  5,  6,  19]. 
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5  ISDN  Conformance  Test  Speciflcations 

The  NIU-Forum's  Confonnance  Test  (CT)  specifications  provide  test  suites  to  be  used  to  verify 
the  confonnance  of  ISDN  equipments  to  the  designated  specification.  They  are  written  in  abstract 
form  so  that  multiple  test  equipment  vendors  may  provide  implementations  of  the  test  suite.  The 
ISDN  Conformance  test  specifications  are  developed  in  the  ISDN  Conformance  Test  (ICOT) 
Working  Group,  and  its  subordinate  Expert  Working  Groups:  the  Abstract  Conformance  Test 
Group  for  layer  1  (ACTl)  and  the  Abstract  Conformance  Test  Group  for  layers  2  and  3  (ACT23). 
The  following  text  details  the  Conformance  Tests  for  ISDN  equipments. 

5.1  Layer  1  BRI 

The  Basic  Rate  Interface  (BRI)  Layer  1  Conformance  Test  specifications  provide  the  requirements 
for  verifying  equipment  conformance  at  layer  1  of  the  ISDN  BRI  user-network  interface.  The 
following  text  details  the  Conformance  Tests  for  layer  1  operation  of  a  BRI. 

•  Future  "U"  Interface 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  layer  1  BRI  conformance  test 
abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl.601-1988  (Ref  [12]). 

•  The  "S/T"  Interface 

The  CT  defining  the  conformance  criteria  and  abstract  test  suites  to  verify  equipment 
implementation  conformance  to  the  BRI  S  and  T  interface  as  specified  in  ANS  Tl. 605-1989  (Ref 
[16])  is  defined  by  the  NIU-Forum  specification,  NIU  90-002  (NIU-F/IIW/ICOT-90-040)  Integrated 
Services  Digital  Network  (ISDN)  Conformance  Testing,  Layer  I  Basic  Rate  S/T  Interface,  User 
Side,  (Ref  [33]). 

5.2  Future  Layer  1  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  layer  1  PRI  conformance  test 
abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl. 408-1990  (Ref  [11]). 

5.3  Layer  2  BRI 

The  layer  2  Conformance  Test  specifications,  for  the  BRI  and  PRI  access  arrangements,  provide 
the  requirements  for  verifying  equipment  conformance  at  layer  2  of  the  ISDN  BRI/PRI.  The  ISDN 
test  suite  development  process  is  aligned  with  International  Standards  Organisation  (ISO)  9646 
(Ref  [54]),  OSI  Conformance  Testing  Methodology  and  Framework,  Parts  1-3.  The  following  text 
details  the  Conformance  Tests  for  layer  2  operation  of  an  ISDN. 

The  CT  defining  the  abstract  test  suites  to  verify  equipment  implementation  conformance  to  the 
layer  2  of  an  ISDN  at  the  user-network  interface  is  defined  by  the  NIU-Forum  specification,  NIU 
91-007^  (NIU-Forum/IIW/ICOT/ACT-9 1/22.2  VI. 2)  Integrated  Services  Digital  Network  (ISDN) 
Conformance  Testing,  Layer  2  Basic  Rate  Interface,  Link  Access  Procedure,  D-channel  (LAPD), 
User  Side,  (Ref  [34]).  This  conformance  test  suite  is  for  the  Link  Access  Procedure,  D-channel 


^In  order  to  accuiately  represent  the  Layer  2  Confonnance  tests,  the  reference  was  changed  from  NIU 
89-001  (NIU-Fonim/IIW/IC(JT/89-065.2)  to  the  final,  and  NIU-Forum  approved  document  NIU  91-007 
(NIU-Forum/IIW/ICOT/ACT23-9 1  -22.2  V 1 .2). 
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(LAPD)  data  link  protocol  and  is  described  in  Tree  and  Tabular  Combined  Notation  (TTCN).  Its 
use  is  for  ISDN  terminal  equipments  attaching  to  the  user  side  of  a  Basic  Access  interface. 

The  CT  defines  the  conformance  criteria  to  the  ANS  Tl. 602-1989  (Ref.  [13])  and  to  the  CCITT 
Recommendation  Q.921-1988  (Ref.  [25])  (Note:  These  specifications  are  the  same  text).  The 
purpose  of  the  Abstract  Test  Suite  is  to  provide  the  most  complete  protocol  conformance  test 
coverage  as  is  possible,  not  to  be  completely  exhaustive.  The  LAPD  Test  Suite  has  many 
additional  test  cases  for  TEI  Management  procedures  and  system  related  cases  which  are  covered 
in  the  body  of  the  CCITT  Reconunendation  Q.921-1988  text  (Ref.  [25])  but  not  in  the  CCITT 
Recommendation  Q.921-1988  state  transition  tables. 

5.4  Future  Layer  2  PRI 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  layer  1  PRI  conformance  test 
abstract  test  suites,  and  conformance  criteria  to  the  ANS  Tl.602-1989  (Ref.  [13]). 

5.5  Future  Layer  3 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  the  layer  3  Conformance  Test 
specifications,  for  BRl  and  PRI  access  arrangements. 
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6  Application  Software  Interface  (ASI) 

This  section  includes  the  introductory  material  for  the  specification  for  an  Application  Software 
Interface  (ASI)  defined  by  the  NIUF.  The  complete  ASI  documents  are  published  separately. 

6.1  Introduction  To  The  ASI 

6.1.1  Overview 

Part  1  of  the  ASI  provides  an  initial  specification  intended  to  allow  implementors  to  begin  using 
the  ASI  for  implementations  of  applications  requiring  a  limited  subset  of  ISDN  services  within  a 
limited  set  of  operating  systems.  The  specification  includes  the  following  components: 

•  introduction  to  the  ASI  concepts, 

•  description  of  the  ASI  architecture, 

•  description  of  the  ASI  access  functionality, 

•  ASI  command  messages  to  support  a  basic  subset  of  ISDN  services, 

•  and  ASI  data  structures. 

Future  parts  of  the  ASI  specification  will  expand  the  above  list  to  include: 

•  ASI  access  method  for  DOS,  UNIX/POSIX,  OS/2,  Windows,  etc., 

•  additional  ASI  command  messages  to  support  additional  ISDN  services, 

•  formal  specification  of  the  ASI, 

•  expansion  to  include  the  full  teleservices  architecture, 

•  and  conformance  tests. 

6.1.2  Charter 

The  Application  Software  Interface  focuses  on  the  definition  of  a  common  application  interface  for 
accessing  and  administering  ISDN  services  provided  by  hardware  commonly  referred  to  in  the 
vendor  community  as  Network  Adapters  (NAs)  and  responds  to  the  applications  requirements 
generated  by  the  ISDN  Users'  Workshop  (lUW). 

The  characteristics  of  this  Application  Interface  shall  be: 

•  portable  across  the  broadest  range  of  system  architectures, 

•  extensible, 

•  abstracted  beyond  ISDN  to  facilitate  interworking. 
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•  and  defined  in  terms  of  services  and  facilities  consistent  with  OS  I  layer  interface 
standards. 

6.1.3  Goals 

The  primary  goal  of  the  AS  I  is  to  provide  a  consistent  set  of  application  software  interface  services 
and  application  software  interface  implementation  agreement(s)  in  order  that  an  ISDN  application 
may  operate  across  a  broad  range  of  ISDN  vendor  products  and  platforms. 

The  application  software  interface  implementation  agreements  will  be  referenced  by  (and  tested 
against)  the  lUW  generated  applications.  It  is  anticipated  that  the  vendor  companies  involved  in 
the  development  of  these  implementation  agreements  will  build  products  for  the  ISDN  user 
marketplace  which  conform  to  them. 

ASI  Implementation  Agreements  are  likely  to  become  a  U.S.  Government  Federal  Information 
Processing  Standard  (HPS). 

ASI  specifications  are  expected  to  serve  as  a  contribution  for  further  North  American  or 
International  standards  activities. 

6.1.4  Purpose 

Today  there  exists  an  ever  increasing  number  of  ISDN  Network  Adapters  (NAs)  from  different 
manufacturers,  each  with  the  same  basic  subset  of  features,  plus  additional  features  the 
manufacturers  hope  will  differentiate  them  from  the  competition.  This  environment  is  illustrated 
in  figure  6-1. 


Figure  6-1.  Typical  Proprietary  Interface  Enviroiunent. 
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Currently,  each  NA  vendor  presents  a  different  software  interface  to  the  ISDN  application.  This 
produces  constant  frustration  to  the  ISDN  applications  developer.  Each  interface  represents  the 
efforts  on  the  part  of  the  vendor  to  provide  access  to  all  ISDN  services  provided  by  the  NA;  yet 
each,  done  in  isolation,  differs  from  the  others.  In  developing  an  ISDN  application,  therefore,  the 
developer  is  faced  with  the  task  of  (a)  binding  with  an  initial  NA  (hopefully  a  popular  one),  and 
(b)  once  his  application  is  fielded,  working  to  enhance  his  application  product  to  interface  with 
other  NAs  as  well.  Exemplifying  this  process  are  products  in  the  market  today  which  advertise 
"currently  works  with  Network  Adapters  A,  B,  and  C;  will  support  Network  Adapters  D  and  E  in 
the  near  future." 

6.1.5  Scope 


Figure  6-2  conceptualizes  a  solution  to  the  application  interface  incompatibility  problem. 


Figure  6-2.        ASI  Environment. 


The  ASI  is  a  software  interface  between  an  application  and  a  NA  within  an  operating  environment 
(the  operating  environment  includes  the  operating  system,  hardware  platform,  bus,  etc.).  Elements 
on  the  network  side  of  the  interface  are  referred  to  as  the  "ASI  Entity  (AE)."  Elements  on  the 
application  side  are  referred  to  as  the  "Program  Entity  (PE)." 

The  ASI  does  not  guarantee  interoperability  between  the  end  to  end  applications  that  may  use  the 
ASI. 

The  ASI  places  emphasis  on  a  common  application  interface  as  opposed  to  a  common  hardware 
device  interface  for  two  main  reasons: 
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1.  The  most  important  user  benefit  is  derived  from  a  large  selection  of  commercially 
available  ISDN  applications  which  can  operate  over  a  correspondingly  large  selection  of 
NAs.  The  number  of  applications  will  be  most  influenced  by  the  existence  of  a  common 
application  interface  that  allows  the  application  provider  to  easily  migrate  applications  to 
different  NAs  or  operating  system  environments. 

2.  It  is  much  more  difficult  to  specify  a  standard  hardware  device  interface.  Vendors 
want  to  provide  different  NA  hardware  interfaces  to  appeal  to  different  markets.  For 
example,  some  NAs  will  be  built  for  performance  while  others  will  be  built  for  low  cost. 
The  market  that  a  vendor  desires  to  sell  into,  will  determine  the  hardware  device  interface 
(i.e.,  memory  mapped,  polled  I/O,  interrupt  driven,  direct  memory  access  (DMA)  driven, 
shared  memory,  etc.).  Vendors  are  accustomed  to  providing  drivers  or  libraries  which 
interface  to  their  specific  hardware  implementation. 

The  conversion  from  the  common  ASI  to  the  NA  hardware  device  interface  becomes  the  job  of 
the  adapter  developer.  The  conversion  function  can,  for  instance,  reside  in  a  device  driver  which 
is  provided  by  the  adapter  manufacturer.  The  application  developer  should  have  to  do  as  little  as 
possible  to  port  an  application  written  for  one  operating  system  to  a  different  operating  system 
(e.g.,  to  re-compile  or  re-link  is  perceived  as  minimal  effort).  Also,  within  one  operating  system, 
the  application  developer  should  be  able  to  design  applications  independently  of  the  NA  (e.g.,  the 
application  should  work  the  same  and  without  modification  on  the  variety  of  NAs  available), 
assuming  the  NA  provides  equivalent  services. 

The  conceptual  objective  of  the  ASI  is  to  be  as  independent  as  possible  of: 

•  Hardware  Platform, 

•  Operating  System, 

•  Data  Protocol  Type, 

•  Programming  Language, 

•  and  Compiler. 

Although  the  ASI  takes  the  approach  of  developing  a  common  set  of  services  which  are  applied 
across  a  broad  range  of  environments,  the  access  methods  are  environment  dependent.  This  is  true 
because  of  hardware  restrictions  within  different  operating  environments,  performance  issues,  and 
fundamental  operating  system  differences. 

As  applicable  ISDN  standards  evolve  it  is  expected  that  the  ASI  will  evolve  to  accommodate  those 
applicable  standards. 

6.1.6  Assumptions 

Several  assumptions  have  gone  into  the  development  of  the  current  ASI  specification.  These 
assumptions  are  described  as  follows: 

•  ISDN  primary  rate  and  basic  rate  access  are  assumed  to  be  the  network  interface  to  the 
NA.  This  does  not  preclude  application  of  this  interface  to  NAs  which  interface  to  other 
ISDN  access  methods. 
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•  The  ASI  provides  a  uniform  software  interface  defined  between  the  NA  and  the 
application.  Throughout  the  ASI  specification,  the  term  "ASI  entity"  is  used  to  refer  to 
the  ISDN  service  provider,  and  any  associated  hardware,  network  adapter  card,  or  terminal 
equipment,  while  the  term  "Program  Entity"  is  used  to  refer  to  the  application  which  uses 
the  ISDN  service. 

•  This  specification  does  not  address  peer-to-peer  protocol  or  interoperability  issues. 

•  The  ASI  interface  is  assumed  to  be  at  the  OSI  layer  three  to  layer  four  boundary. 

•  ANSI  Standards,  NIUF  Agreements,  and  CCITT  Reconmiendations  are  the  basis  for 
this  ASI  specification. 

•  No  default  values  for  parameters  are  assumed  by  the  interface.  All  parameter  values 
necessary  for  a  message  must  be  suppUed  in  the  applicable  data  structures. 

6.2  Technical  Overview 

This  section  presents  an  overview  of  the  ASI  architecture  and  the  motivation  underlying  the  chosen 
approach. 

The  goal  of  the  ASI  is  to  provide  a  portable,  extensive,  and  layered  software  interface  to  ISDN 
hardware,  call  control,  and  services.  Portability  allows  applications  to  be  developed  independent 
of  any  particular  vendor's  ISDN  offering,  and  hence  ties  the  success  of  the  application  to  the 
penetration  of  ISDN  rather  than  the  future  of  a  single  vendor.  Portability  favors  the  application 
developer  by  making  the  application  available  for  a  wider  audience.  But  widespread  application 
availability  will  make  it  easier  to  use  ISDN  services,  hastening  deployment  of  ISDN  Hues,  and  thus 
ultimately  benefitting  the  hardware  (or  ISDN  capable  computer  platform)  vendors  as  well. 

ASI  applications  run  on  a  computer  platform  employing  ISDN  interface  hardware  from  different 
vendors  without  recompilation  or  linking.  The  same  application  is  portable  to  a  different  computer 
platform  (with  the  same  operating  system)  by  recompiling  without  changes  to  the  source  code. 
There  may  be  some  code  changes  required  for  a  different  operating  system  to  accomodate 
differences  in  the  access  method. 

A  problem  with  designing  application  software  interfaces  to  ISDN  teleservices  is  the  range  of  level 
of  functionality  such  an  interface  could  support.  A  high  level  interface  would  provide  generic 
telephony  interface  functions,  while  a  lower  level  would  more  closely  match  ISDN-specific 
message  and  event  types.  The  ASI  favors  a  layered  approach,  based  on  experience  with  the  OSI 
model  and  numerous  examples  in  distributed  computing. 

As  such,  the  ASI  incorporates  a  model  with  several  reference  points.  A  multi-tasking  operating 
system  will  enable  multiple  processes  to  gain  access  to  ISDN  services  through  a  server  architecture 
which  will  provide  a  high  level  functional  interface  and  event  filtering  to  minimize  ISDN-specific 
knowledge  required  of  the  application.  This  server,  or  the  single  application  for  a  server-less  or 
single  threaded  operating  system,  in  turn  communicates  with  ISDN  call  conttol  over  a  lower  level 
interface  which  more  closely  mirrors  the  ISDN  protocol.  The  various  reference  points  will  be 
illustrated  later  in  this  section. 

The  current  release  of  the  ASI  specification  defines  the  core  subset  of  the  lower  level  reference 
point.  It  is  to  this  reference  point  which  vendors  must  supply  ASI  support,  and,  once  written,  early 
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applications  can  be  developed  immediately.  No  vendor-specific  software  need  operate  above  this 
reference  point,  although  a  vendor  may  choose  to  provide  higher  level  support  for  added  value  to 
an  ISDN  product. 

The  ASI  defines  a  reference  point  and  a  message  protocol  across  that  reference  point.  ISDN  call 
control  and  hardware  specific  interfaces  will  operate  below  the  ASI  and  be  provided  by  specific 
vendors.  Vendors  may  also  supply  an  application  library,  in  some  specific  programming  language, 
to  compose  messages  in  the  ASI  format. 

The  ASI  specifies  a  complete  interface  composed  of  an  operating  system  dependent  access  method, 
an  operating  system  independent  message  set,  and  an  operating  system  independent  message 
encoding  method.  An  operating  system  dependent  access  method  allows  the  rest  of  the  ASI  to 
exist  independent  of  the  OS. 

Because  the  message  set  and  encoding  method  are  identical  between  the  various  implementations 
of  the  ASI  for  different  operating  systems,  application  portability  is  greatly  simplified. 

The  ASI  message  set  and  operating  system  specific  access  methods  provide  an  asynchronous 
interface  to  ISDN  call  control.  The  application  makes  requests  through  the  ASI,  and  the  ISDN  call 
control  beneath  the  ASI  transmits  confirmation  messages  and  event  indication  messages  back 
through  the  ASI  as  appropriate.  Any  blocking  or  synchronous  interface  to  the  ASI  should  be 
provided  as  a  Ubrary  of  function  calls  on  the  application  side  of  the  ASI. 

For  example,  an  application  places  a  call  by  sending  an  Nb-CONNECT  request.  After  issuing  the 
request,  the  application  can  continue  execution.  Call  control  may  generate  various  Nb-EVENT 
indication  messages  as  the  call  proceeds  through  the  network.  When  the  call  completes  to  the 
called  party,  an  Nb-CONNECT  confumation  message  will  be  sent  up  through  the  ASI.  To 
implement  a  blocking  call  request,  the  application  would  send  the  Nb-CONNECT  request,  and 
await  the  Nb-CONNECT  confiimation. 

6.2.1  Application  Software  Interface  Definition 

'  The  Apphcation  Software  Interface  (ASI)  is  a  common  interface  for  accessing  ISDN  services 
provided  by  ISDN  network  adapters  (NAs).  The  ASI  is  a  way  for  an  application  and  an  ASI  entity 
to  communicate  within  an  operating  environment  (the  operating  environment  includes  the  operating 
system,  hardware  platform,  bus,  etc.).  The  translation  of  the  ASI  message  set  to  and  from  the 
instructions  needed  to  operate  any  hardware  interfaces  is  accomplished  by  AE  vendor  supplied 
software.  The  conversion  function,  can,  for  instance,  reside  in  a  device  driver  provided  with  the 
AE. 

The  application  developer  should  be  able  to  design  applications  independent  of  the  NA  with  which 
it  might  be  used.  Within  a  given  operating  environment  (e.g.,  a  PC  running  DOS),  applications 
should  be  able  to  run  on  any  ASI-compliant  AE.  Finally,  the  application  developer  should  have 
to  do  as  little  as  possible  (e.g.,  recompile/relink)  in  order  to  move  from  one  operating  system  to 
another.  Tlie  ASI  allows  any  ISDN  application  written  against  the  ASI  specification  to 
communicate  with  any  ASI-compliant  ISDN  network  service  provider. 


NIU-Forum  Agreements  on  ISDN 


6.2.2  OSI  Reference  Model  Positioning 

The  ASI  is  positioned  at  the  Service  Access  Point  (SAP)  between  layers  3  and  4  in  the  OSI 
Reference  Model.  Conceptually,  the  ASI  is  an  asynchronous  message  stream  between  the  ISDN 
network  services  provider  (layers  1-3)  and  the  user  (layers  4+)  of  those  services. 

If,  for  example,  a  non-empty  transport  layer  protocol  is  positioned  above  the  ASI,  then  that 
transport  protocol,  and  not  the  higher  layer  application,  is  the  actual  user  of  the  ISDN  bearer 
services  provided  through  the  ASI.  Likewise,  the  term  "ASI  entity"  is  meant  to  apply  to  any 
provider  of  ISDN  network  services  that  meets  certain  qualifying  assumptions.  The  ASI  is  a  local 
interface  between  layer  4  and  layer  3  only;  it  is  not,  itself,  a  layer  within  the  OSI  Reference  Model, 
nor  is  it  an  end-to-end  protocol.  Such  features  as  interoperability  or  end-to-end  integrity  must  be 
provided  by  protocols  above  the  ASI,  using  ISDN  network  services  accessed  through  the  ASI. 

6.2.3  Teleservices  Architecture 

The  environment  in  which  the  ASI  is  expected  to  operate  assumes  an  architecture  including  a 
generic  teleservices  server.  Such  a  server  may  offer  teleservices  to  applications  on  the  local 
machine  or  on  the  local  area  network  without  requiring  the  applications  to  implement  the  details 
of  ISDN,  plain  old  telephone  service  (POTS)/public  switched  telephone  network  (PSTN),  or  other 
possible  teleservices  media. 

It  would  be  the  responsibility  of  a  server  interface  definition  to  allow  for  multiple  client 
applications  to  access  the  services  provided  by  a  single  interface  adapter. 

The  teleservices  architecture  has  been  spUt  into  several  layers.  Issue  1  ASI  is  identified  as  the 
message  stream  at  reference  point  "B"  in  this  architecture. 

The  definition  of  the  Reference  Points  is  as  follows,  and  is  depicted  in  figure  6-3: 

•  In  ASI  Draft  1,  the  "A"  reference  point  is  not  an  exposed  interface.  It  is  defined  to  be 
the  interface  between  the  "standard"  portions  of  Q.931  and  the  non-standard  portions. 
Only  the  non-standard  portions  of  ISDN  need  to  be  customized  for  each  market. 

•  The  "B"  reference  point  is  the  interface  between  the  ISDN  signaling,  management  and 
user  planes,  and  a  server  or  dedicated  application.  Direct  multi-client  access  is  not 
allowed. 

•  The  "C"  reference  point  presents  a  generic  teleservices  interface  to  the  server  or 
dedicated  application. 

•  The  "D"  reference  point  allows  a  server  to  provide  a  generic  teleservices  interface  to 
multiple  client  applications.  This  interface  also  presents  a  simplified  programming  model 
to  the  application  or  toolkit  developer. 

•  The  "E"  reference  point  is  the  programming  interface  provided  by  a  high  level  library. 
This  interface  is  the  one  most  desired  by  typical  applications  developers. 
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Teleservices  Architecture  for  Call  Control 
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Figure  6-3.        Teleservices  Architecture  for  Call  Control. 


6.2.4  ASI  Sessions 


The  Application  Entity  (AE)  and  Program  Entity  (PE)  communicate  across  the  ASI  by  reference 
to  sessions.  A  session  is  a  local  virtual  path  between  the  PE  and  the  AE  which  carries  all  requests 
and  responses  for  a  given  instance  of  a  service,  e.g.,  a  voice  call.  Once  established,  a  session  is 
referred  to  by  a  session  ID. 

Sessions  are  created  dynamically  by  either  the  AE  or  the  PE  according  to  the  rules  defined  by  the 
ASI  protocol.  To  allow  for  dynamic  creation  of  sessions  by  either  side,  each  side  may  create 
session  IDs  without  consulting  the  other  side.  The  AE's  session  ID  is  referred  to  as  the  AEI,  while 
the  PE's  session  ID  is  referred  to  as  the  PEL  Either  side  may  refer  to  a  session  using  the  other's 
ID.  An  ID  of  all  zeros  indicates  that  the  other  side's  ID  is  unknown  or  is  not  used. 


Retiring  and  reuse  of  old  IDs  is  carefully  managed  by  the  protocol. 
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6.2.5  ASI  Components 

The  ASI,  or  any  other  interface  in  the  architecture,  must  contain  definitions  for  the  following: 

•  access  methods  for  each  operating  environment  (DOS,  Unix,  etc.),  for  passing  messages, 

•  a  set  of  message  types  and  associated  parameters, 

•  precisely  defined  encodings  for  the  above  messages, 

•  and  a  formal  description  of  the  protocol  semantics. 

6.2.5.1  Access  Methods 

An  access  method,  as  defined  by  this  document,  is  an  operating  system  dependant  set  of  procedures 
for  passing  messages  between  layers  of  software.  The  messages  may  contain  control,  management, 
or  user  plane  information. 

This  architecture  requires  that  any  access  method  provides  asynchronous  message  passing  between 
software  layers. 

Access  methods  are  described  in  the  Application  Software  Interface  Part  1:  Overview  and 
Protocols  (Ref.  [53]),  section  4. 

6.2.5.2  Messages 

In  order  to  meet  the  portability  and  network  transparency  requirements  of  the  architecture,  all 
messages  are  required  to  be  self  contained.  Messages  containing  pointers,  or  other  references,  to 
external  data  structures  are  not  legal. 

Messages  and  their  semantics  are  described  in  Application  Software  Interface  Part  I:  Overview 
and  Protocols  (Ref.  [53]),  section  5.  Message  parameters  are  described  in  Application  Software 
Interface  Part  1:  Overview  and  Protocols  (Ref.  [53]),  section  6. 

6.2.5.3  Encoding 

Message  definition  will  be  described  using  ASN.l. 

Actual  message  encoding  will  be  done  using  an  ASI  specific  method.  The  method  is  chosen  to 
promote  ease  of  implementation  and  improve  performance  while  providing  for  future  expansion 
of  the  protocol. 
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7  Application  Profiles 


Since  the  inception  of  the  NIU-Forum,  the  goal  has  been  to  provide  an  ISDN  that  users  want  and 
need,  and  to  do  so  in  a  way  that  promotes  application  interoperability  in  a  multi-vendor 
environment.  Application  profiles  are  the  final  step  in  the  functional  standardization  process  to 
achieve  this  goal. 

7.1  NIU-Forum  Application  Profiles 

An  application  profile  provides  an  overall  specification  of  the  ISDN  elements  and  the  application 
elements  necessary  to  provide  a  specific,  interoperable  application  for  an  ISDN.  A  profile  supports 
a  particular  application,  or  a  set  of  applications,  specifying  the  ISDN  standards  to  use,  the  options 
to  implement  within  each  standard,  the  layered  protocol  configuration  and  the  application's  usage 
of  the  ISDN's  attributes.  Please  refer  to  the  North  American  ISDN  Users'  Forum  (NIU-Forum) 
Working  Agreements  for  the  Integrated  Services  Digital  Network  (ISDN)  —  Publication  1,  (Ref. 
[32]),  section  7.1.1,  for  a  description  of  the  process  for  developing  Application  Profiles. 

7.1.1  Application  Profile  Conformance 

It  is  essential  that  the  Application  Profile  teams  identify  criteria  that  the  implementor  must  meet 
in  order  to  claim  compliance  with  the  Application  Profile.  It  is  intended  that  a  tester  agency  be 
established  (e.g.,  the  Corporation  for  Open  Systems)  which  applies  ICOT-derived  conformance  tests 
in  order  to  verify  a  product's  relative  sufficiency  of  interoperability  against  a  testbed  which  applies 
standardized  tesUng  methodologies  (e.g.,  ISO  9646,  Ref.  [54]).  Real  multi-vendor  interoperabihty 
is  achieved  in  an  interoperabihty  testing  environment  which  validates  the  Application  Profile's 
compliance  amongst  participatory  users  and  vendors. 

7.1.2  Application  Profile  Families 

The  NIU-Forum  ISDN  applications  have  been  categorized  into  one  of  six  "application  families." 
The  families  provide  a  means  of  assimilating  applications  based  upon  a  commonality  of  usage. 

Each  family  has  been  assigned  its  own  Application  Profile  team  to  develop  the  Application  Profiles 
for  tlie  family.  The  following  Application  Profile  teams  have  been  identified: 

•  ISDN  Call  Management 

•  ISDN  CPE  Compatibility/Capability 

•  ISDN  Network  Interconnectivity 

•  Messaging  and  Answering 

•  Bandwidth  Negotiation 

•  Network  Management/ISDN  Administration 

The  following  sections  detail  the  Application  Profile  lAs.^ 


^The  NIU-Forum  Plenary  document  numbers  (e.g.,  NIU  90-003)  are  included  for  reference  purposes 
only,  as  every  numbered  application  profile  is  included  in  the  present  document  in  its  entirety. 
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7.2  ISDN  Call  Management 
7.2.1  Incoming  Call  Management 

The  ISDN  Call  Management  Profile  team  has  completed  an  Application  Profile,  NIU  90-003,  for 
incoming  call  management  which  covers  all  of  the  following  apphcations: 

Title  User  Req't  Document  Number 

•  Database  Information  to  Corporate  Security  810005 

•  New  Account  Customer  Inquiry  Handhng  840023 

•  Customer  Service  Call  Handling  840024 

•  Automatic  Callback  for  Financial  Services  840025 

7.2.1.1  Abstract 

This  application  profile  provides  the  User  Descriptions,  Alternative  Architectures,  Information 
Flows,  and  recommended  Protocol  Stacks  for  the  Incoming  Call  Management  Applications  (User 
Application  Requirements  Data  Form  Numbers:  810005,  840023,  840024,  840025,  Refs.  [36,  37, 
38,  39]).  The  Incoming  Call  Management  Applications  involve  customer  service  agents  who 
currently  receive  incoming  calls,  ask  the  caller  for  their  member  number,  and  input  that  data  into 
a  terminal  connected  to  a  host  application.  ISDN  will  be  used  to  automate  the  transfer  of  the 
Caller's  ID  to  the  host.  In  addition,  agents  may  transfer  the  call  to  an  additional  agent  who  should 
be  able  to  continue  the  call  without  having  to  request  the  same  information  from  the  caller  again. 
ISDN  will  be  used  to  effect  the  call  transfer  and  allow  the  second  agent  to  bring  up  the  right 
application  screen  without  repeating  questions.  Finally,  when  all  the  agents  are  busy,  the  caller's 
number  should  be  captured  for  later  callback.  ISDN  will  be  used  to  capture  the  caller's  number 
and  allow  callback  later.  ISDN  can  be  used  to  connect  the  agent's  terminal  to  the  host. 

7.2.1.2  User  Description 

Customer  service  agents  currently  receive  incoming  calls,  ask  the  caller  for  their  member  number, 
and  then  input  the  member  number  into  a  terminal  connected  to  a  host  application  to  obtain  the 
customer  information.  Agents  may  transfer  the  customer  to  another  agent  to  provide  a  different 
service.  The  second  agent  has  to  again  ask  for  the  member  number  and  enter  a  transaction  to 
receive  the  customer  information.  The  second  agent  may  access  a  different  host  application.  In 
addition,  when  all  agents  are  busy,  the  caller's  number  should  be  captured  for  later  callback. 

7.2.1.3  ISDN  Application  Breakdown 

The  user's  proposed  application  and  the  breakdown  of  the  application  into  service  elements  can 
be  seen  in  figure  7-1. 

•  Call  Transfer  with  Associated  Data  Service  Element 

Agent  1  wishes  to  transfer  a  voice  call  from  the  Customer  to  agent  2.  The  voice  call  is 
transferred  to  agent  2.  Certain  information  associated  with  the  terminal  session  is 
transferred  to  the  host  to  which  agent  2  is  attached,  so  that  the  appropriate  screen  can  be 
delivered  to  agent  2. 


NIU-Forum  Agreements  on  ISDN 


•  Call  Delivery  with  Associated  Data  Service  Element 

The  customer  places  a  voice  call  in  order  to  speak  to  an  agent.  The  call  arrives  at  a 
Central  Office  (Co)  or  Customer  Premises  switch  (PBX).  The  switch  delivers  the  voice 
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Figure  7-1. 


User  Proposed  Application  Service  Breakdown. 
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call  to  agent  1.  Certain  information  that  is  delivered  to  the  switch  with  the  voice  call 
(probably  the  calling  party's  number)  is  delivered  to  a  host  application,  so  that  the  host 
application  can  deliver  an  appropriate  screen  to  agent  1. 


•  Call  Back  on  Busy/ Abandonment  Service  Element 

This  service  allows  an  available  agent  to  place  calls  to  customers  who  have  received  busy 
or  abandoned  the  call  prior  to  delivery  to  an  agent. 

•  Terminal  Connectivity  Service  Element 

The  agents  data  terminal  is  connected  to  the  host  via  an  ISDN  hnk. 
7.2.1.3.1  Service  Logic 

Figure  7-2  shows  the  sequence  of  services  put  together  to  provide  Incoming  Call  Management 
Applications.  The  Terminal  Connectivity  Service  Element  may  be  optional  and  a  Call  coming  in 
without  the  associated  data  (Calling  Line  Identification  (CLID)  may  be  available  for  Call  Transfer 
with  associated  data. 

7.2.1.4  Call  Transfer  with  Associated  Data  Service  Element 

In  this  service  a  call  is  ah-eady  active  between  agent  1  and  the  caller.  Agent  1  could  then  perform 
any  of  the  following: 

1.  Blind  Transfer  —  Transfer  the  call  to  a  second  agent  and  disconnect  before  the 
second  agent  answers. 

2.  Transfer  with  Consulting  —  Transfer  the  call  to  a  second  agent,  discuss  the  call  with 
the  second  agent,  then  complete  the  transfer. 

3.  Consult  —  Agent  1  calls  the  second  agent  to  discuss  the  call  and  then  disconnects 
agent  2. 

The  components  are  shown  in  figure  7-3. 
The  sequence  of  events  for  each  type  is: 
Blind  Transfer 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2  and  invokes  transfer. 

c.  Agent  1  hangs  up. 

d.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (Automatic  Call 
Distributor  (ACD)  function). 


The  topic  of  how  the  switch  decides  to  deliver  the  call  to  a  particular  agent  has  not  been  described  as 
part  of  this  application,  but  may  have  some  bearing  on  implementation. 
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Figure  7-2.        Incoming  Call  Management  Application  Logic  Flow. 
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e.  Agent  2  receives  the  voice  call,  while  concurrently  a  host^  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 
2. 

Transfer  with  Consulting 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2. 

c.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (ACD  function). 

d.  Agent  2  receives  the  voice  call,  while  concurrently  a  host  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 
2. 

e.  Agent  1  talks  with  agent  2. 

f.  Agent  1  transfers  the  caller  to  agent  2  and  disconnects. 
Consulting 

a.  Agent  1  places  the  caller  on  hold. 

b.  Agent  1  places  a  call  to  agent  2. 

c.  Agent  2  is  selected  directly  or  by  an  intervening  CO/PBX  (ACD  function). 

d.  Agent  2  receives  the  voice  call,  while  concurrently  a  host  application  brings  up 
an  appropriate  screen  based  on  some  information  delivered  with  the  call  to  agent 
2. 

e.  Agent  1  talks  with  agent  2. 

f.  Agent  2  disconnects. 

The  information  being  passed  along  with  the  call  will  be  called  the  Key.  The  Key  may  be  any  of 
the  following: 

•  a  database  key  used  by  the  agent's  application, 

•  the  Calling  Party  Number, 

•  an  Application  or  Screen  ID, 

•  some  other  information  used  by  the  users  application, 

•  or  a  combination  of  the  above. 


^The  host  that  the  application  is  running  on  may  be  the  same  for  both  agents  or  different. 
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7.2.1.4.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

IBM  3270^  type  terminals 
An  IBM-compatible  host 
•     SNA  (Systems  Network  Architecture)  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.4.2  Alternative  Architectures 

Two  architectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NIU-Forum).  The  first  architecture  calls  for  the  Call  information  to  be  delivered  to  the  agent's 
station  or  terminal  adapter  (TA)'°  and  then  have  that  device  transmit  it  to  the  host  application  (see 
fig.  7-4).  If  the  agent's  station  is  sufficiently  intelligent  (e.g.,  a  personal  computer),  the  station 
could  run  the  application  locally. 

The  second  architecture  calls  for  the  Host  to  provide  the  central  office  or  customer  premises  switch 
with  the  Key,  and  that  Key  is  passed  to  agent  2's  Host  (see  fig.  7-5).  The  call  is  delivered  to  the 
agent's  station  normally.  The  data  terminal  could  be  attached  to  the  host  directly  or  be  attached 
using  the  ISDN  Terminal  Connectivity  Service  Element  described  in  section  7.2.1.7. 

7.2.1.4.3  Information  Flow 

The  information  flow  diagrams  show  that  data  that  must  be  sent  between  nodes  necessary  to 
provide  the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation 
messages,  error  messages,  disconnect)  are  not  shown  for  simplicity  if  they  are  not  necessary  to 
explain  the  working  of  the  service. 

The  information  flow  for  Architecture  1  —  Smart  Terminal/TA  can  be  seen  in  figure  7-6. 

Agent  I  places  a  call  (Call  Setup)  which  is  deUvered  to  agent  2's  station  with  the  Key  (carried  as 
User  to  User  information).  Agent  2's  station  could  generate  an  appropriate  screen  using  the  Key 


^Trademark  of  IBM  Corporation 

'"This  requires  intelligence  not  normally  associated  with  a  TA  to  satisfy  the  requirement  that  any  3270- 
like  device  were  to  be  able  to  use  this  service.  A  separate  functional  entity,  and  Intelligence  Unit  (lU),  will 
be  described  as  providing  the  service  of  relaying  Call  information  to  the  host.  In  effect  this  unit  would 
upgrade  the  3270  to  an  intelligent  terminal  with  an  attached  voice  terminal.  The  TA-intelligence  unit  will 
have  to  be  able  to  have  a  separate  session  to  the  host  running,  so  the  data  can  be  passed.  Alternately,  but 
more  complex,  the  Intelligence  Unit  would  have  to  be  able  to  understand  the  screens  being  passed  between 
the  host  and  the  terminal  and  insert  information  in  the  data  stream. 
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Figure  7-4.        Call  Transfer  with  Data  Service  Element  Architecture  1  —  Smart  Terminal/TA. 
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Figure  7-6.        Call  Transfer  with  Data  Service  Element  Smart  Terminal/TA  —  Information  Flow 
Diagram. 


7-10 


NIU-Forum  Agreements  on  ISDN 


or  the  station  could  then  transfer  the  Key  to  the  host.  The  host  application  would  then  select  and 
transmit  the  appropriate  screen  to  agent  2's  terminal. 

The  information  flow  for  Architecture  2  —  Switch  Host  interface  can  be  seen  in  figure  7-7. 

The  call  would  be  initiated  by  agent  1  selecting  to  transfer  via  the  terminal.  The  terminal  would 
transfer  this  information  to  the  host  ("Init  Call").  The  host  would  then  transmit  this  to  the  PBX/CO 
along  with  the  Key  as  User  to  User  information  ("Init  Call  (Key)").  The  PBX/CO  the  second  agent 
is  attached  to  would  transmit  the  call  setup  information  to  agent  2's  station.  Simultaneously  the 
PBX/CO  would  send  the  call  setup  information  (including  the  user  to  user  information  containing 
the  Key)  to  the  host  computer.  The  host  selects  and  transmits  the  appropriate  screen  to  agent  2's 
terminal. 

In  both  flows,  if  consulting  is  desired  instead  of  completing  the  transfer,  agent  2  would  disconnect. 

7.2.1.4.4  Network  Signalling  Requirements  —  Protocol  Identification 

The  network  signalling  requirements  for  providing  this  service  with  each  architecture  are  shown 
in  figures  7-8  and  7-9.  Not  shown  is  how  the  call  was  originally  received,  since  it  may  have  come 
in  via  ISDN  or  POTS.  The  requirement  for  this  capability  is  that  the  end-points  involved  in  the 
call  transfer  must  be  connected  via  end-to-end  ISDN  signalling  so  that  user-to-user  information  can 
be  exchanged. 

In  figures  7-8  and  7-9,  any  connection  between  two  devices  without  a  specific  protocol  marked 
may  use  any  applicable  protocol  including  a  proprietary  one. 

7.2.1.4.5  Protocol  Description 

The  messages  and  protocol  elements  desaibed  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.4.5.1  Call  Setup  User  Information 

The  Key  can  be  carried  from  the  origination  to  destination  terminal  in  the  SETUP  message 
described  in  NIU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B).  The  SETUP 
Message  described  as  sent  to  the  network  and  by  the  network  to  the  called  user  to  initiate  call 
estabhshment. 

The  information  element  used  to  carry  the  Key  would  be  the  User-User  information  element 
described  as  follows:  "The  purpose  of  the  User-user  information  element  is  to  convey  information 
between  ISDN  users.  This  information  is  not  interpreted  by  the  network,  but  rather  is  carried 
transparently  and  delivered  to  the  remote  user(s).  There  are  no  restrictions  on  the  content  of  the 
user  information." 


NIU-Forum  Agreements  On  ISDN 


7-11 


Agent  1  Agent  2 


Host  1  and  Host  2  may  be  the  same 
PBX/CO  and  PBX/CO'  may  be  the  same 

Figure  7-7.        Call  Transfer  with  Data  Service  Element  Switch  Host  Interface  —  Information  Row 


Diagram. 


Agent  1 


Agent  2 


0  B  D 
SOD 
ODD 
0    0  0 


ISDN\  ISDN 


HOST 


Figure  7-8. 


ISDN 


ISDN 
BRI 


PBX/CO 
(ACD) 


PBX/CO 
(ACD) 


HOST 


Call  Transfer  with  Data  Service  Element  Smart  Terminal/TA 
Requirements. 


Network  Signalling 


7-12 


NIU-Forum  Agreements  on  ISDN 


Agent  1 


Agent  2 


ISDN 
Network 


Figure  7-9.        Call  Transfer  with  Data  Service  Element  Switch  Host  Interface 
Requirements. 


Network  Signalling 


NIU-Forum  Agreements  On  ISDN 


7-13 


7.2.1.4.5.2  Call  Transfer 


Proposed  baseline  text  for  the  Normal  Call  Transfer  supplementary  service  exists  within  TIS  1.2/91- 
309,  Supplementary  Service  —  Normal  Call  Transfer  Stage  1,  2,  and  3,  (Ref.  [22])."  There  is 
no  consensus  on  the  protocol  description  for  this  service  yet. 

7.2.1.4.5.3  Host-Switch  Messages 

The  functions  that  need  to  be  provided  to  allow  this  service  are  the  following: 

•  Send  User-User  information  (Key)  and  initiate  a  call. 

•  Receive  User-User  information  (Key)  on  an  incoming  call. 

Possibly  initiate  the  call  transfer  operation,  this  could  be  done  from  the  voice  terminal 
directly. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Draft  Proposed  Standard,  TIS  1/92-629  (Ref.  [23]). 

7.2.1.5  Call  Delivery  with  Associated  Data  Service  Element 

In  this  service  an  agent  is  available  to  receive  an  incoming  call.  When  a  customer's  call  is 
presented  to  the  agent  an  appropriate  screen  is  displayed  on  the  agent's  data  terminal  that  relates 
to  the  caller  or  the  application  being  provided  by  the  agent  (see  fig.  7-10). 

The  sequence  of  events  is  as  follows: 

a.  Caller  places  a  call  to  the  phone  number  of  the  "Call  Delivery  service  user"  (800 
number  in  some  user's  application). 

b.  An  agent  is  selected  by  the  CO/PBX  (ACD  function). 

c.  The  agent  receives  the  voice  call,  while  concurrently  a  host  application  brings  up  an 
appropriate  screen  (based  upon  the  calling  party's  number). 

7.2.1.5.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

•  IBM  3270  type  terminals 

•  An  IBM-compatible  host 
SNA  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 


"There  is  also  ongoing  work  within  ANSI  to  define  Explicit  Call  Transfer  and  Single  Step  Call  Transfer 
Supplementary  Services. 
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Figure  7-10.      Call  Delivery  with  Data  Service  Element  Description. 
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7.2.1.5.2  Alternative  Architectures 


Two  architectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NIU-Forum).  The  first  architecture  calls  for  the  Call  information  to  be  delivered  to  the  agent's 
station  or  terminal  adapter  (TA)'^  and  then  have  that  device  transmit  it  to  the  host  application  (see 
fig.  7-11).  If  the  agent's  station  is  sufficiently  intelligent  (e.g.,  a  personal  computer),  the  station 
could  run  the  application  locally. 

The  second  architecture  calls  for  the  Host  to  provide  the  central  office  or  customer  premises  switch 
with  the  Key,  and  that  Key  is  passed  to  agent  2's  Host  (see  fig.  7-12).  The  call  is  delivered  to  the 
agent's  station  normally.  The  data  terminal  could  be  attached  to  the  host  directly  or  be  attached 
using  the  ISDN  Terminal  Connectivity  Service  Element  described  in  section  7.2.1.7. 

7.2.1.5.3  Information  Flow 

The  information  flow  diagrams  show  the  data  that  must  be  sent  between  nodes  necessary  to  provide 
the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation  messages, 
error  messages,  disconnect)  are  not  shown  for  simphcity,  if  they  are  not  necessary  to  explain  the 
working  of  the  service. 

The  information  flow  for  Architecture  1  —  Smart  Terminal/TA  can  be  seen  in  figure  7-13. 

The  call  is  delivered  to  the  agent's  station  with  the  Calling  Party  Number  (CPN).  The  station  will 
generate  an  appropriate  screen  locally  or  by  interacting  with  a  host  application. 

The  information  flow  for  Architecture  2  —  Switch  Host  interface  can  be  seen  in  figure  7-14. 

The  Switch  transmits  the  call  setup  information  to  the  agent's  station  and  the  host  computer 
simultaneously.  The  host  selects  and  transmits  the  appropriate  screen. 


'^This  requires  intelligence  not  normally  associated  with  a  TA  to  satisfy  the  requirement  that  any  3270- 
like  device  were  to  be  able  to  use  this  service.  A  separate  functional  entity,  and  Intelligence  Unit  (lU),  will 
be  described  as  providing  the  service  of  relaying  Call  information  to  the  host.  In  effect  this  unit  would 
upgrade  the  3270  to  an  intelligent  terminal  with  an  attached  voice  terminal.  The  TA-intelligence  unit  will 
have  to  be  able  to  have  a  separate  session  to  the  host  running,  so  the  data  can  be  passed.  Alternately,  but 
more  complex,  the  Intelligence  Unit  would  have  to  be  able  to  understand  the  screens  being  passed  between 
the  host  and  the  terminal  and  insert  information  in  the  data  stream. 
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Figure  7-11.      Call  Delivery  with  Data  Service  Element  Architecture  1  —  Smart  Terminal/TA. 
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Figure  7-12.      Call  Delivery  with  Data  Service  Element  Architecture  2  —  Switch  Host  Interface. 
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Figure  7-13.      Call  Delivery  with  Data  Service  Element  Smart  Terminal/TA  —  Information  Flow 
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7.2.1.5.4  Network  Signalling  Requirements  —  Protocol  Identification 

In  order  to  implement  this  service,  certain  signalling  capabilities  are  required  in  the  user  and  carrier 
networks.  Figures  7-15  and  7-16  identify  what  are  the  signalling  requirements  at  each  point  in  the 
network.  As  can  be  seen  in  the  diagrams  the  requirements  for  signalling  within  the  network  are 
the  same  for  the  smart  terminal  and  switch-host  scenarios,  but  there  are  differences  within  the 
premises. 

EAMF  stands  for  Equal  Access  Multi-Frequency  which  can  be  used  to  pass  the  Calling  Party 
Number.  Any  connection  between  two  devices  without  a  specific  protocol  marked  may  use  any 
applicable  protocol  including  a  proprietary  one. 

7.2.1.5.5  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.5.5.1  Call  Setup  User  Information 

The  Calling  Party  Number  can  be  carried  from  the  origination  to  destination  terminal  in  the 
SETUP  message  described  in  NIU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B). 
The  SETUP  message  is  described  as  sent  to  the  network  and  by  the  network  toward  the  called  user 
to  initiate  call  establishment. 

The  Information  needed  to  carry  the  Calling  Party  Number  is  described  in  a  paragraph  titled 
Calling  Party  Number.  "The  Purpose  of  the  Calling  party  number  information  element  is  to 
identify  the  origin  of  the  call."  The  information  element  may  say  that  the  number  is  not  available, 
the  application  must  be  able  to  handle  this  situation  appropriately. 

7.2.1.5.5.2  Host-Switch  Messages 

The  necessary  function  required  by  this  service  is  the  handling  of  the  incoming  Calling  Party 
Number. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Draft  Proposed  Standard,  TIS 1/92-629  (Ref.  [23]). 
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Figure  7-15.      Call  Delivery  with  Data  Service  Element  Smart  Terminal/TA 
Requirements. 
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7.2.1.6  Call  Back  on  Busy/Abandonment  Service  Element 

In  this  service,  no  agents  are  available  to  receive  an  incoming  call.  The  caller  may  do  any  of  the 
following: 

•  receive  Busy  (possible  reasons:  all  agents  busy,  maximum  queue  size), 

•  receive  an  Announcement  (i.e.,  "All  Lines  are  Busy,  An  agent  will  call  you  back 
when  one  becomes  available")  followed  by  disconnect, 

•  or  be  placed  in  a  queue  (possibly  with  an  announcement  "Wait  for  the  next  available 
agent,  if  you  hangup,  an  agent  will  return  your  call")  for  the  next  available  agent  and 
then  disconnect. 

The  caller's  phone  number  will  be  recorded  so  that  an  agent  can  call  back  later  (see  fig.  7-17). 
This  service  cannot  be  invoked,  unless  the  call  is  delivered  to  the  final  switch. 

The  sequence  of  events  is  as  follows: 

1.  Caller  places  a  call  to  the  phone  number  of  the  "Call  Delivery  service  user"  (800 
number  in  one  user's  apphcation). 

2.  The  calling  line  id  is  recorded  by  a  host  application. 

3.  The  treaunent  may  be  busy,  an  announcement  and  disconnect,  or  being  placed  in  a 
queue.  If  the  caller  was  placed  in  a  queue,  they  are  subsequently  disconnected. 

4.  Agent  obtains  the  number  from  the  application  software  and  places  a  call. 

7.2.1.6.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

IBM  3270  type  terminals 

•  An  IBM-compatible  host 

•  SNA  host  networks 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.6.2  Architecture 

Two  ai'chitectures  for  this  application  have  been  proposed  and  adopted  (March  1989  and  June  1989 
NlU-Forum).  The  first  architecture  calls  for  the  information  to  be  delivered  to  the  agent's  terminal 
and  the  second  to  a  host  computer.  Only  the  second  architecture  is  considered  here  because  there 
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Caller 


Figure  7-17.      Call  Back  on  Busy /Abandonment  Service  Element  Description. 
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is  no  mechanism  to  pass  information  about  calls  that  have  never  reached  a  station  (i.e..  Caller 
disconnects,  PBX  returns  busy)  to  a  station. 

7.2.1.6.3  Information  Flow 

The  flow  diagrams  show  the  general  information  flow  necessary  to  provide  the  service  described. 
Some  messages  that  are  normally  present  (i.e.,  confirmation  messages,  error  messages,  disconnect) 
are  not  shown  if  they  are  not  necessary  to  explain  the  working  of  the  service. 

The  flow  diagram  for  call  abandonment  can  be  seen  in  figure  7-18.  The  call  setup  information, 
including  Calling  Party  Number  (CPN)  goes  across  the  network.  The  Switch  transmits  the  call 
setup  information  (CPN)  to  the  host  computer.  The  caller  then  "Disconnects"  and  the  host 
computer  is  informed,  so  it  puts  the  number  in  a  list  for  later  callback.  At  a  later  time,  the  agent 
interacts  with  the  host  and  selects  a  callback  number.  The  agent  can  then  either  generate  the  call 
via  the  host  or  dial  the  number  using  the  phone.  Figure  7-19  is  the  flow  diagram  for  the  case 
where  the  caller  receives  busy  or  hears  an  announcement. 

7.2.1.6.4  Network  Signalling  Requirements 

The  network  signalling  requirements  for  this  service  are  the  same  as  for  Call  Delivery  using  the 
Switch  to  Host  interface  (see  fig.  7-16). 

7.2.1.6.5  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

7.2.1.6.5.1  Call  Setup  User  Information 

The  Customer  identifier  can  be  carried  from  the  origination  to  destination  terminal  in  the  SETUP 
message  described  in  NIU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B).  The 
SETUP  message  is  described  as  sent  by  the  calling  user  to  the  network  and  by  the  network  to  the 
called  user  to  initiate  call  establishment. 

The  Information  needed  to  carry  the  Calling  Party  Number  is  found  in  the  paragraph  titled  Calling 
Party  Number.  "The  purpose  of  the  Calling  party  number  information  element  is  to  identify  the 
origin  of  the  call."  The  information  element  may  say  that  the  number  is  not  available,  the 
application  must  be  able  to  handle  this  situation  appropriately. 

7.2.1.6.5.2  Host-Switch  Messages 

The  necessary  function  required  by  this  service  is  the  handling  of  the  incoming  Calling  Party 
Number. 

The  Host  Computer  messages  are  being  described  in  the  ANSI  Switch-Computer  Applications 
Interface  (SCAI)  Draft  Proposed  Standard,  TIS 1/92-629  (Ref.  [23]). 
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7.2.1.7  Terminal  Connectivity  Service  Element 


This  service  provides  connectivity  between  a  terminal  and  a  host  using  an  ISDN  link.  This  is 
illustrated  in  figure  7-20. 

The  sequence  of  events  is  as  follows: 

a.  The  user  causes  a  call  to  be  placed  from  the  terminal  to  a  port  on  the 
host/controUer.'^ 

b.  Upon  connection  of  the  call  the  data  transport  protocol  is  initiated. 

c.  When  the  data  session  is  complete  the  call  is  disconnected. 

7.2.1.7.1  User  Environment 

Some  of  the  users'  descriptions  of  the  service  have  specified  a  hardware  and  software  environment 
in  which  the  service  should  work.  At  a  minimum,  the  service  should  work  in  the  following 
environment: 

•  IBM  3270  type  terminals 

•  An  IBM-compatible  host 

•  SNA  host  networks. 

These  are  minimum  requirements  and  the  actual  description  of  the  service  is  more  general  in  that 
it  will  work  with  other  terminals,  hosts,  and  networks. 

7.2.1.7.2  Information  Flow 

The  information  flow  diagrams  show  the  data  that  must  be  sent  between  nodes  necessary  to  provide 
-    the  service  described.  Signalling  messages  that  are  normally  present  (i.e.,  confirmation  messages, 
error  messages,  disconnect)  are  shown  for  simphcity  if  they  are  not  necessary  to  explain  the 
working  of  the  service. 

The  flow  diagram  in  figure  7-21  shows  the  general  information  flow  necessary  to  provide  the 
described  service. 


'^The  use  of  some  ISDN  features  for  security  (i.e.,  CLID)  may  be  required,  but  are  not  part  of  the  user 
application  description  (text  or  figures). 
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Figure  7-20.      Terminal  Connectivity  Service  Element  —  Description. 
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7.2.1.7.3  Network  Protocol  Requirements 

The  network  protocol  requirements  for  this  service  can  be  seen  in  figure  7-20.  As  shown  in  that 
figure,  there  needs  to  be  ISDN  connectivity  between  the  terminal  and  the  point  where  it  is  attached 
to  the  computer  or  controller. 

The  higher  layer  protocols  for  carrying  the  user  data  are  not  described  here.  The  Network 
Interconnectivity  Profile  Team  should  provide  the  higher  level  protocol  specification  when 
completing  Application  Profiles  for  the  User  Application  Requirements  Data  Forms  numbered: 
830008,  830009,  960009  (Refs.  [40,  41,  42]). 

7.2.1.7.4  Protocol  Description 

The  messages  and  protocol  elements  described  below  are  only  those  required  by  the  service  being 
described.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the 
application  being  described,  even  through  they  may  be  required  for  other  reasons,  such  as  routing 
of  the  call. 

The  protocol  described  in  NIU  90-301  (see  Appendix  A)  and  NIU  90-302  (see  Appendix  B)  can 
be  used  for  the  setup  and  breakdown  of  the  call  being  made  to  carry  the  data  protocol. 

The  only  information  element  that  may  have  a  direct  bearing  on  the  service  is  in  the  SETUP 
message  described  as  "sent  by  the  calling  user  to  the  network  and  by  the  network  to  the  called  user 
to  initiate  call  establishment."  The  information  element  is  the  Bearer  Capability  Informafion 
Element.  The  user  can  ask  for  the  appropriate  information  transfer  capability  and  transfer  mode. 
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7.2.1.8  Protocol  Summary  and  Status 

The  following  is  a  summary  of  the  protocol  requirements  of  the  Incoming  Call  Management 
Application. 

Table  7-1.  Protocol  Requirements  for  Incoming  Call  Management  Application  Profile 


Application 
Service  Element 

Protocol  Element 

Document 

Call  Transfer 

With  Associated  Data 

User — User 

NIU  90—301  &  NIU 
90 — 302  Implementation 
Agreements 

Call  Transfer 

TIS  1.2/92— 185  (Ref.  [22]) 

Hn<jt  Switch 

TlSl/92  629  SCAI  Draft 

Proposed  Standard,  (Ref. 
[23]) 

Call  Delivery 

With  Associated  Data 

Calling  Party  Number 

NIU  90—301  &  NIU 
90 — 302  Implementation 
Agreements 

Host— Switch 

TIS  1/92— ^29  SCAI  Draft 
Proposed  Standard,  (Ref. 
[23]) 

Terminal  Connectivity 

Bearer  Capability 

NIU  90—301  &  NIU 
90 — 302  Implementation 
Agreements 

Higher  Layer 

Network  Interconnectivity 
Family 

Call  Back 

Calling  Party  Number 

NIU  90—301  &  NIU 
90 — 302  Implementation 
Agreements 

Host— Switch 

TIS  1/92— 629  SCAI  Draft 

Proposed  Standard,  (Ref. 
[23]) 
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7.3  ISDN  CPE  Compatibility/Capability 


7.3.1  Building  Controls 

This  application  profile,  NIU  91-002,  provides  User  Descriptions,  Terminal  Adapter  Functional 
Requirements  and  Application  Architecture  Analysis  for  the  Building  Controls  Application 
830013.0,  (Ref.  [43]). 

7.3.1.1  User  Description 

The  Building  Controls  application  consists  of  a  variety  of  control  functions  carried  out  with  the 
objective  of  monitoring  and  managing  a  building  and  its  facilities  in  a  cost  effective  manner.  Some 
of  the  representative  functions  are: 

•  Control  of  heating/ventilation  and  air  conditioning  equipment. 

•  Energy  management. 

•  Comfort  control. 

•  Fire  monitoring  and  facility  control  in  a  fire  situation. 

•  Security  monitoring  and  control. 

•  Control  of  personnel  access  to  restricted  areas. 

The  application  currently  consists  of  the  following  components: 

•  Sensors  that  are  attached  to  key  metering  equipment. 

•  The  sensors  are  connected  to  control  processors  which  either  store  information  or 
initiate  action  based  on  the  sensor  readings.  This  connection  is  proprietary  in  nature  and 
will  not  utilize  ISDN  services. 

•  Up  to  31  control  processors  can  be  connected  to  a  central  processor  in  a  multidropped, 
polled  environment.  The  central  processor  stores,  sorts  and  relays  data  received  from  its 
associated  control  processors.  Additionally  it  provides  an  operator  interface  and  transmits 
stored  information  to  the  end  customer's  host  computer. 

In  the  typical  implementation  in-house  wiring  is  used  to  connect  the  central  processor  and  its 
associated  control  processors.  The  interface  used  is  RS-485  providing  synchronous  communication 
between  1200  and  9600  bps. 

Control  processors  can  also  be  connected  remotely  over  private  line  facilities.  The  physical 
interface  in  this  implementation  is  RS-232  providing  synchronous  or  asynchronous  communication 
between  1200  and  9600  bps.  The  asynchronous  format  is  more  common  and  utilizes  either  an  8 
bit  or  9  bit  data  format. 

The  link  from  the  central  processor  to  the  customer's  host  utilizes  an  RS-232  interface  which 
provides  synchronous  or  asynchronous  communication  at  2400  bps. 

This  profile  will  focus  on  uulizing  ISDN  services  for  connections  between  1)  the  control  and 
central  processors,  and  2)  the  central  processor  and  customer  host  computer. 

7.3.1.2  Terminal  Adapter  Functional  Requirements 

Table  7-2  provides  a  summary  of  the  basic  functionality  required  for  terminal  adapters  to  operate 
in  this  application.  This  summary  assumes  the  use  of  D-Channel  permanent  virtual  circuits  and  B- 
Channel  packet  services  between  the  central  and  control  processors. 
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The  link  from  the  central  processor  to  the  host  computer  will  utilize  B-Channel  circuit  data 
services.  The  Application  Architecture  discussion  in  section  7.3.1.3  describes  the  ISDN  data 
services  to  be  used. 


Table  7-2.  Building  Control  Application  Functional  Requirements 


Feature 

Central 
Processor 

T  A 

Control 
Processor 

TA 

Customer 
Host 

TA 

RS-232  Async  "R"  Interface 

Option 

Yes 

Yes 

RS-232  Sync  "R"  Interface 

Yes 

Option 

Yes 

RS-485  Sync  "R"  Interface 
Proprietary  Protocol 

Option 

Option 

No 

9  Bit  Async  Data 

Option 

Option 

Option 

8  Bit  Async  Data 

Option 

Yes 

Yes 

NOTES: 

1)  An  answer  of  "Yes"  means  that  support  for  this  feature  is  required. 

2)  An  answer  of  "Option"  means  that  support  for  this  feature  appears  desirable  but  may 
not  be  required. 

3)  An  answer  of  "No"  means  that  support  for  this  feature  is  not  required. 

4)  The  round  trip  transit  time  for  a  poll  and  corresponding  response  through  the  network 
should  not  exceed  50  ms.  This  is  exclusive  of  processing  time  at  the  Control  Processor. 

5)  The  data  word  formats  used  are  8  data  bits  +  no  parity  and  8  data  bits  +  1  parity  bit. 

6)  Currently  the  Central  Processor  can  support  up  to  31  Control  Processors.  This  number 
may  be  increased  at  a  future  date. 

7.3.1.3  Application  Architecture 

The  application  architecture  is  based  on  the  use  of  D-Channel  permanent  virtual  circuits  to  each 
control  processor.  A  nailed-up  B-Channel  packet  service  is  used  to  connect  the  appropriate  control 
processors  to  the  central  processor.  This  approach  implies  that  the  cenu-al  processor  will  substitute 
X.25  for  layers  1,  2  and  3  of  the  proprietary  protocol  that  is  currently  used.  The  use  of  PVC's  and 
nailed-up  connections  reasonably  emulates  the  current  multidropped  environment  and  negates  any 
requirement  for  the  processor  and  terminal  adapter  to  exchange  commands  for  call  setup  or  call 
clearing. 

The  central  processor  uses  a  file  transfer  facility  to  transmit  information  to  the  customer's  host 
computer.  Either  D-Channel  packet  or  B-Channel  circuit  switched  data  services  could  be  used  to 
support  this  requirement. 

Figure  7-23  illustrates  the  topography  of  this  application. 
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7.3.1.3.1  Layer  1  Architecture 


The  layer  1  architecture  for  this  application  is  fully  supported  by  T1.605  (Ref.  [16]).  Each  control 
processor  will  function  in  a  Point  to  Point  environment;  however,  Point  to  Multipoint  arrangements 
may  be  considered  where  distance  limitations  can  be  met. 

7.3.1.3.2  Layer  2  Architecture 

The  layer  2  architecture  for  this  application  is  fully  supported  by  X.25  (Ref.  [28])  LAPB 
procedures  on  the  B-Channel  and  T1.602  (Ref.  [13])  LAPD  procedures  on  the  D-Channel. 

7.3.1.3.3  Layer  3  Architecture 

The  layer  3  architecture  for  this  application  is  fully  supported  by  T1.608  (Ref.  [18]). 

7.3.1.3.3.1  Central  Processor  Terminal  Adapter  Architecture 

Terminal  adapters  attached  to  the  cenu-al  processor  would  utilize  B-Channel  packet  services  to 
allow  the  central  processor  to  poll  up  to  3 1  control  processors.  This  implementation  requires  that 
the  central  processor  utilize  X.25  for  layers  1,  2  and  3  of  the  proprietary  protocol  and  imphes  that 
the  X.25  data  will  presented  in  a  standard  HDLC  format. 

The  physical  interface  provided  would  be  RS-232  and  would  support  speeds  up  to  9600  bps.  The 
requirement  to  support  RS-485  is  discussed  in  section  7.3.1.3.3.5  (Issues  And  Limitations). 

The  terminal  adapter  used  for  data  transfer  to  the  customer's  host  would  utilize  B-Channel  circuit 
data  services.  The  physical  interface  provided  is  RS-232  and  it  would  support  either  asynchronous 
or  synchronous  data  formats  at  speeds  up  to  9600  bps. 

7.3.1.3.3.2  Control  Processor  Terminal  Adapter  Architecture 

A  terminal  adapter  attached  to  a  control  processor  would  utilize  D-Channel  PVC  packet  services. 
PVC's  are  required  to  support  the  following  requirements: 

•  Round  trip  delay  within  network  should  not  exceed  50  ms.  The  use  of  virtual  circuits 
would  not  meet  this  requirement. 

•  Control  processor  must  be  able  to  transmit  alarm  information  immediately  to  the  central 
processor. 

The  terminal  adapters  utilizing  D-Channel  packet  services  would  interface  to  control  processors  as 
follows: 

•  RS-232  interface 

•  Asynchronous  data 

•  8  bit  word  format 

•  Speeds  up  to  9600  bps 

The  following  interface  support  is  discussed  in  section  7.3.1.3.3.5  (Issues  And  Limitations): 

•  RS-485  interface 

•  Synchronous  data 

•  9  bit  word  format 
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7.3.1.3.3.3  Customer  Host  Terminal  Adapter  Architecture 

The  customer  host  terminal  adapter  would  utilize  B-Channel  circuit  data  services  to  communicate 
with  the  central  processor.  D-Channel  packet  services  could  be  considered,  however,  the  terminal 
adapter  could  not  currently  support  synchronous  data. 

The  physical  interface  required  is  RS-232  and  will  support  speeds  up  to  9600  bps.  The  data  format 
can  be  either  asynchronous  or  synchronous. 

In  the  asynchronous  mode  the  terminal  adapter  may  have  to  provide  a  command  interface  to  allow 
the  establishment  and  clearing  of  calls.  Alternatively  an  autodial  mechanism  may  be  provided 
which  will  dial  a  stored  number  when  the  DTE  provides  an  appropriate  signal  e.g.,  Data  Terminal 
Ready. 

In  the  synchronous  mode  an  autodial  mechanism  could  also  be  considered. 


7.3.1.3.3.4  Protocol  Architecture  Overview 


The  protocol  stack  shown  below  illustrates  the  peer  to  peer  communications  in  the  architecture 
described  above. 
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Figure  7-22.  Building  Controls  Protocol  Stack. 


7.3.1.3.3.5  Issues  And  Limitations 


The  following  issues  are  raised  by  this  architecture: 


1)  There  are  currently  no  standards  that  define  the  interface  between  a  synchronous  DTE 
and  X.25  packet  assembler/disassembler  (PAD). 
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2)  There  are  currently  no  standards  that  support  the  use  of  9  bit  data  from  a  start/stop 
DTE  on  an  X.25  network.  The  requirement  to  octet  align  the  data  for  transport  on  the 
network  may  require  significant  development. 

3)  The  addition  of  RS-485  interfaces  to  terminal  adapters  will  require  significant 
development. 

4)  The  requirement  for  a  50  ms  round  trip  transit  time  for  a  poll  and  response  may  not 
be  achievable  in  all  cases. 

The  following  limitations  are  imposed  by  this  architecture: 

1)  The  central  processor  will  have  to  substitute  X.25  for  layers  1,  2  and  3  of  the 
proprietary  protocol. 
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Figure  7-23.  Building  Controls  Application  Topography. 
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7.4  ISDN  Network  Interconnectivity 
7.4.1  Data  Conferencing  (Point-to-Point) 

This  proposed  Application  Profile  (pAP)  for  application  810004  (Ref.  [35])  Data  Conferencing 
(Point-to-Point)  is  distinguished  from  that  of  ISP  application  profiles  for  ISDN/OSI  functional 
standards. 

The  Attachments  are  either  tutorial  in  nature  or  provide  information  as  to  extensions  for  pAP 
810004.  When  pAP  is  progressed  through  the  IIW  Expert  Working  Groups,  it  will  then  achieve 
a  status  of  approved  Apphcation  Profile  (aAP).  As  contained  herein,  pAP  810004  is  a  first-order 
approach  to  identifying  particular  profiles  that  need  to  be  expanded  in  the  sense  of  Implementors' 
Conformance  Statements  (ICS),  PICS,  and  Requirements  List  (RL)  that  encompass  both  the 
application  environment  and  the  ISDN/OSI  environment. 

7.4.1.1  Scope 

The  pAP  810004  delineates  a  set  of  profiles  that  identify  the  service/protocol  specifications  needed 
in  order  to  comply  with  the  ISDN  functional  standards  (de  jure)  for  aAP  810004. 

pAP  810004  is  point-to-point  data  conferencing.  Multi-way  (multi-peer)  data  conferencing  is 
outside  the  scope  of  pAP  810004.  pAP  810004  is  limited  to  circuit-switched  profiles.  pAP  810004 
logical  or  physical  reahzations  are  outside  this  scope,  unless  they  are  implicit  in  the  cited  reference 
model  or  standards  for  pAP  810004. 

De  facto  aspects  (NETbios)  of  pAP  810004  have  been  mandated  by  the  lUW  of  the  NIU-Forum. 
Circuit  switched  facilities  are  also  stipulated  by  the  lUW.  OSI  profiles  are  cited  if  they  have  been 
defined  by  other  SPOs'. 


7.4.1.2  Field  Of  Application 

pAP  810004  in  its  future  state  (aAP  810004)  coupled  with  NIU  Forum  implementation  agreements 
will  govern  compliant  product  implementations  (physical  realizations)  of  point-to-point  data 
conferencing  over  public  or  private  wide-area  ISDNs. 

Customer  premise  environments  have  either  BRA  or  PRA  network  termination  and  may  involve 
LANs,  PBXs  or  Private  Switched  Networks  (PSN). 

7.4.1.3  References 

ISO  DISP  AFTnn-1:  1989  (E);  Source:  Standards  Promotion  and  Application  Group  (SPAG). 

COS  Profile  Selection  (1989-1990)  Final  Draft  Version  2.0,  May  25,  1989. 

ISPBX  Networking  by  ECMA,  TR/NTW,  2nd  Draft,  agreed,  April  1988. 

ISO  XX:  1989  (E),  Information  Processing  Systems  -  XX  -  Common  Upper  Layer  Requirements. 

NetBIOS  Interface  to  ISO  Transport  Services  and  Name  Service  Protocol  Specification  89-00-0001- 
TNS  (MAP/TOP) 

'Standards  PromoUon  Organizations  such  as  NIST,  ETSI,  INTAP,  COS,  MAPA^OP.  et  al. 
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ISO  TR/10000,  Information  Processing  Systems  -  International  Standardized  Profiles,  ISO/IEC 
JTCl/SGFS 

Part  1  -  Taxonomy  Framework  N109,  1989-02-15 
Part  2  -  Taxonomy  of  Profiles  N126,  1989-04-13 

CCITT  I.Series  Bluebook 

ISO  9646  OSI  Conformance  Testing  Methodology  and  Framework 
7 AAA  Deflnitions 
Table  7-3.  Definitions 


Definitions 


pAP  -  oriented 


1.  ICS* 


2.  ISPICS' 


3.  pAP/ICS 


4.  PICS 

5.  Profile* 


6.  Requirements  List 
(RL) 


'adapted  from  DTR/10000-1 


Implementation  Conformance  Statement  is  a 
statement  by  the  vendor  (as  constrained  by  the 
applicable  profiles  and  PICS)  regarding  the 
implemented  product's  compliance  with  the  base 
standard(s),  profiles,  PICS  and  the  requisite 
conformance  options. 

International  Standardized  Profiles  Implementation 
Conformance  Statement  which  aligns  ISP  features,  functions 
or  options  in  the  sense  of  static  conformance  requirements. 
This  alignment  includes  base  standards,  the  profiles,  and 
implementation  choices. 

is  equivalent  to  a  pAP/RL  (which  is  provided  for  each  profile 
in  a  pAP)  but  shows  the  general  options  of  the  profile  (as  a 
whole)  coupled  with  a  list  of  protocols  selected  and  combined 
in  the  Profile  as  reflected  in  the  PICS 

protocol  implementation  conformance  statement 

a  profile  makes  explicit  the  relationships  between  a  set  of 
standards  used  together.  A  pAP/ICS  is  the  equivalent  of  a 
PICS.  The  pAP/ICS  emphasizes  function,  service  options  and 
features.  The  PICS  concentrates  on  the  protocol  parameters, 
ranges,  or  characteristics. 

it  is  the  purpose  of  an  RL  to  specify  the  NIU-Forum  pAP/RL 
Profile's  constraints  on  what  may  appear  in  the  "Support"  and 
"non-support"  (values  etc.)  columns  in  the  relevant  pAP  and 
PICS  pro  forma. 
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7.4.1.5  pAP  810004  Requirements  List 
Table  7-4.  General  Level  Plus  Scenario  Level 


Field  of  Application  (RL)  810004 

A.A  PUBLIC  Services 

A.B  PRIVATE  Services 

A.C  HYBRID  Services 

User/Provider  Feature  Set        (RL)  810004 

X.U  Peer  User(s)  Types 

X.R  Server  Types 

X.D  Domain  Types 


Table  7-5.  General  Level  plus  Scenario  Level  plus  Functional  Level 

Field  of  Application     (RL)  810004 

A.Al  User's  CPE  -  Public  Service 

A.A5  Peer  User  CPE  -  Public  Service 

A.Bl  User's  CPE  -  Private  Service 

A.B6  Peer  User's  CPE  -  Private  Service 

A.C1  User's  CPE  -  HYBRID  Service 

A.C7  Peer  User's  CPE  -  HYBRID  Service 

User/provider  Feature  Set         (RL)  810004 

X.IF  no  peer  user 

X.2F  one  (1)  peer  user 

X.5F  server  co-incident  with  user 

X.6F  servers  are  symmetric 

X.4F  one  domain  (multi-in-sessions) 

X.8F  symmetric  peer  domains  (multi- 
in-sessions) 
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Table  7-6.  All  810004  "leafs" 


Field  of  Application  (RL)  810004  branch 

leafs 


A.All 

TEl 

PUBLIC 

A.A12 

TE2 

PUBLIC 

A.A13 

NT2 

PUBLIC 

A.A14 

PSN 

ism 

PUBLIC 

A.A57 

NTl 

(T) 

PUBLIC 

A.A58 

peer 

user  LLP 

PUBLIC 

A.A59 

peer 

user  HLF 

PUBLIC 

A.Bll 

TEl 

PRIVATE 

A.B12 

TE2 

PRIVATE 

A.B13 

NT2 

PRIVATE 

A.B14 

PSN 

(SAT) 

PRIVATE 

A.B67 

NTl 

(T) 

PRIVATE 

A.B68 

peer 

user  LLP 

PRIVATE 

A.B69 

peer 

user  HLP 

PRIVATE 

A.Cll 

TEl 

HYBRID 

A.C12 

TE2 

HYBRID 

A.C13 

NT2 

(sm 

HYBRID 

A.C14 

PSN 

(sm 

HYBRID 

A.Cll 

NTl 

(T) 

HYBRID 

A.C78 

I>eer 

user  LLP 

HYBRID 

A.C79 

peer 

user  HLP 

HYBRID 

Table  7-7.  Requirements  List 

User/provider  Feature  Set  (RL)  810004 

leafs 


X.15d  file  transfer,  NetBIOS  (no  peer) 

X.25d  file  transfer,  NetBIOS  (pt-to-pt) 

X.55d  file  transfer,  NetBIOS  (co-incident) 

X.65d  file  transfer,  NetBIOS  (symmetric) 
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7.4.1.6  pAP  810004  Conformance  Requirements 

See  reference  section  7.4.1.5  for  details. 


Table  7-8.  Conformance  Requirements 


RT 

pAProfiles 

r^nn  form  Jin 

pAP 

Supported  on 

option 

810004 

features 

rPF 

ISDN 

A.Al 

X,  M,Q 

I,  M 

m 

A.A5 

X,  M,Q 

I,  M 

m 

A.Bl 

X,  M,Q 

I,  M 

0 

A.B6 

X,  M,Q 

I,  M 

0 

A.Cl  (ffs) 

Q,  V 

I,  M 

o 

A.C7  (ffs) 

Q,  V 

I,  M 

0 

X.2 

X,  M.Q 

1,  M 

m 

X.6 

X,  M,Q 

I,  M 

m 

X.8  (ffs) 

X,  M,Q 

I,  M 

0 

X.25d 

X,  M,  Q 

I,  M 

m 

X.65d  (ffs) 

X,  M,Q 

I,  M 

0 

M  profiles  are  different  at  CPE  than  ISDN  environments 
m  =  mandatory  conformance 
o  =  optional  conformance 
ffs  =  for  further  study 


7.4.1.7  pAP  810004  Configurator 

Note:  the  following  section  contains  all  of  the  information  from  the  810004  application 
requirements  and  application  analysis  documents. 

Figure  7-24,  Figures  7-26  and  7-27,  and  Table  7-13  used  in  this  section  depict  the  basis  for  a  pAP 
810004  Configurator.  The  notion  of  a  "configurator"  enables  functional  (e.g.,  service  overview- 
Table  7-13)  and  logical  (figs.  7-24,  7-26  and  7-27)  models  to  abstract  Uie  pAP  810004  application 
and  connectivity  details. 
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Table  7-9.  Requirements  Stipulated  by  the  lUW  as  Augmented  by  the  IIW/AAG 


NIU-Forum/810004  must  want 

interworking  public  private  (PSN) 

de  facto  industry  LAN  protocols  NETbios  PC/LAN 

LAN-type  access  to  databases  X 

LAN-type  ACCESS  to  data  server  X 

bearer  service  (ckt.  switched)  64  kb/s  128  kb/s 

bearer  service  demand  BRA  or  PRA 

file  transfer  &  sharing  X 

image  (graphics)  flow  X 

PCs  and  servers  (IBM  compat.)  X 

host  with  TA 

multi-peer  X 

multi-sessions  X 

voice  future 

security  No  No 

performance  (128  kb/s  synch'd)  ckt.  switched  ffs 

access  arrangements  departmental  nationwide 

application-independent  X 

PBX/CO-LAN/VPN/CCS  #7/PSN  X 

LAN  media-independent  X 

Addressing  and/or  signalling  I.Series  PSN 
NOTE:  ffs  =  for  further  study 


Adapting  the  ISDN  Reference  Configuration,  the  pAP  810004  configurator  is  depicted  in  figure 
7-24.  This  figure  implies  an  end-to-end  set  of  interworking  (general-level)  profiles  based  on  the 
preceding  values  for  the  "must"  requirements.  This  set  of  profiles  is  in  Table  7-10. 
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Table  7-10.  General-Level  pAP  810004  Profiles 


Source 


Wide-Area 


Destination 


a)  M  (MAP/TOP  NETBIOS) 

b)  V  (file  xfr,  file  sharing) 

c)  Q  =  M  =  I  =  LLF 

d)  X  =  (.U,  .R,  .D) 

e)  A  =  PUBLIC 


I.  Series 
I. Series 
I. Series 
I. Series 
I.Series 


M  (NETbios) 
V  (file  xfr.  ...) 

Q  (...) 
X  ... 
A  ... 


NOTES: 

a)  adopts  the  MAP/TOP  NETbios  Interface  document  and  the  Name  Service  Protocol 
functions. 

b)  enables  high  level  functions  (HLF)  that  denote  file  transfer  and  file  sharing  as  utilized  by 
application-independent  means  (e.g.,  elec.  publishing,  document  sharing,  screen  sharing, 
etc.). 

c)  determines  circuit  switched  bearer  service  of  1  or  2  transparent  B  channels  on-demand. 

d)  addresses  the  user  CPE  as  to  access  arrangements  for  types  of  users,  types  of  servers, 
types  of  domains,  etc. 

e)  isolates  the  field  of  application  aligned  with  bearer,  supplementary  or  teleservice 
functions. 
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USER 


TE 


NT12 


NETWORK 


PUBLIC 
ISDN 


Where  network  facilities  are  circuit  switched 

Where  TE  may  be  a  host  (via  TA&R  reference  point) 


* 

TE 



*  -  NT2  or  NULL 


Where  NT12  may  be: 

A)  PSN  of  one  or  more  ISxyz:    Where  xyz  may  be 

B)  Sub-network  configuration  of  one  or  more  of 

I)  ISLAN 

II)  ISPBX 

III)  Centrex/CO-LAN 

IV)  LAN  GAV  or  IWU 


Figure  7-24.  pAP  810004  Reference  Model 
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Figure  7-26  further  refines  or  simplifies  figure  7-24  to  the  extent  that  the  "basic"  pAP  810004 
products  need  only  deal  with  symmetric  CPE  environments  and  interoperability,  namely: 


v,x 

M,  A 

x,v 

A,M 

Q,A 

A,Q 

I,  A 

I,M 

wide-area 

A,  I 

CPE  CPE 
Source  Destination 

Figure  7-25.  pAP  Profile  Stacks 

This  aligns  the  prior  figure  7-24  discussion  with  the  above  stacks  as  follows: 

b),  d)  =  V,  X  c),  e)  =  Q,  A 

a),  e)  =  M,  A  e),  (w/a)  =  1,  A 

See  notes  a-e  after  General-level  Profile  in  this  section. 

This  alignment  reveals  that  wide-area  (w/a)  ISDN  connectivity  is  based  upon  I. Series  and  SPO  [M] 
profiles  that  are  to  evolve  via  NIST(NIUF),  ETSI(EWOS),  INTAP(AOW),  etc.  for  provider 
services. 
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Figure  7-27  is  the  "extended"  pAP  810004  configurator  which  is  outside  the  scope  of  this  pAP 
810004  (point-to-point)  "basic"  configurator. 


The  purpose  of  including  the  pAP  810004  extended  configurator  is  to  encourage  vendors  to  adopt 
general-purpose  architectural  criteria  when  setting  out  to  meet  pAP  810004  requirements. 

Table  7-11.  Extended  pAP  810004  Configurator* 


ISDN  customer 

Private  Switched 

I 

premise  end-point 

(NT12)  network  (ISDN) 

on-demand 

on-demand 

open 

(B) 

null 

dial-up  (P) 

on-demand 

on-demand 

on-demand 

open 

(B) 

(p)  open  availability 

dial-up  (P) 

(p,P)  shared-facility 

(E) 

+  exclusive-use  (P) 

dial-up 

CUG 

(E) 

exclusive-use  (P) 

dial-up 

(P)  off-net 

(E) 

gateway  (p/P) 

dial-up 

open 

(B) 

null 

CO-LAN 

CUG 

(B) 

null 

PVN 

ISDN  carrier 
network 


dedicated  end-point 
leased 
leased 


dedicated  end-point 
leased 
leased 


pre-established-channels  (E) 

channel  assoc.  signalling 

pre-established-channels  (E) 
shared  facility 
CUG 
off-net 


shared  facility 
CUG 

off-net  (ffs) 


(B) 
(E) 


(B) 
(E) 


(p)  permanent 


dedicated  (leased) 
(p)  pure  ckt.  switched 
(P)  ckt.  switched/ISDN 
signalling  control 

null 


permanent  (p) 
channel  assoc.  signalling 
channel  assoc.  signalling 
channel  assoc.  signalling 
+  gateway  (p/P) 

permanent  (p) 
intra-PSN 
intra-PSN 
intra-PSN 


dedicated  (leased) 

pure  ckt.  switched 

ckt.  switched/ISDN  signalling 
control 

dedicated  (leased) 

pure  ckt.  switched 

ckt.  switched/ISDN  signalling 
control 

permanent  (P) 

ckt.  switched/ISDN  signalling 


ckt.  switched/ISDN  signalling 
ckt.  switched/ISDN  signalling 
ckt.  switched/ISDN  signalling 

permanent  (P) 
invisible 
invisible 
invisible 


P  =  public 
p  =  private 
inUa-PSN  =  PVN 


B  =  basic  configurator 
E  =  extended  configurator 


*deduced  from  ECMA  ISPBX  TR/XX 
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Table  7-13  is  the  overall  framework  for  the  pAP  810004  configurator.  It  is  also  an  overview  of 
a  service  model.  The  properties  of  this  framework  are  addressed  in  the  Attachments. 

The  key  aspects  of  the  table  7-13  framework  include: 

•  the  notion  that  the  carrier  backbone  network  is  augmented  by  a  private  network  backbone  in  the 
sense  of  ISDN  ISP  profiles 

•  such  augmentation  is  facilitated  by  profiles  for  Basic  low  layer  functions  (BLLF)  that  are  aligned 
end-to-end  across  private  and/or  public  sub-networks.  Similarly,  Additional  LLPs  are  so  aligned 
(ALLF).  High-level  functions  may  also  be  augmentations  to  both  the  (basic  and  additional)  carrier 
and  private  backbones 

•  these  Basic  and  Additional  functions  are  provider-oriented  in  the  sense  of  supporting  the  user's 
application  environment.  This  notion  of  augmentation,  when  extended  into  the  user's  application 
environment,  leads  to  further  value-added  application(s)  augmentation  as  the  following  examples 
depict: 

Table  7-12.  pAP  Configurator  Descriptors  (E)  (examples  only) 


User/Provider 

user 

provider 

Feature  Set  Aspects 

VLLF 

VHLF 

VLLF 

VHLF 

service 

B 

B,  A 

B,  A 

application 

S 

N 

S 

N 

features 

interfaces 

S 

S 

•  the  substance  of  the  above  notions,  augmentations  and  alignments,  are  administered  via 
requirements  list(s)  at  each  plateau  (carrier,  private,  CPE).  The  RLs  are  the  fundamental 
application  of  the  pAP  taxonomy  which  is  detailed  in  the  Attachments.  Viewed  as  a  tree  with 
trunk,  branches  and  leaves,  it  enables  each  pAP/RL  to  denote  work  items  or  work-to-be-done  in 
the  sense  of  implementation  agreements. 

backbone-related  descriptors 
where    V  =  value-added  B  =  basic  LLF  or  HLF 

S  =  supported  A  =  additional  LLF  or  HLF 

N  =  non-support 
-  =  profile  RLs 
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Table  7-13.  pAP  810004  Service  Overview 


Customer 
Premise 
Environment 

Wide- Area 
Network 


pAP-8 10004 

User/Provider 

810004 

Field  of  Application 

Feature  Set 

RL 

AHLF 

PSN 

BHLF 

ALLF 

RL 

BLLF 

AHLF 

ISDN 

BHLF 

ALLF 

RL 

BLLF 

RL  -  Requirements  List 
HLF  -  High  Layer  Function(s) 
LLF  -  Low  Layer  Function(s) 
PSN  -  Private  Switched  Network 
B  =  Basic 
A  =  Additional 

NOTE:  PSN  and  ISDN  HLF  and  LLF  May  differ 


7.4.1.8  Attachment  1  —  Proposed  Application  Profile  (pAP)  Overview 

The  following  pAP  concerns  are  separate: 

I.  ISP  Profiles  per  part  1,  section  6  of  TR/IOOOO 

A.  Standards 

B.  Registration  Mechanisms 

C.  Conformance 

II.  IIW  Profiles  per  the  NIU-Forum 

A.  Environment  (Application) 

1.  Application  Requirements  (lUW) 

2.  Application  Analysis  (IIW) 

B.  User/Provider  Interaction 

C.  Application  Requirements  List 

D.  SPO  Profile  Selection 

E.  I. Series  Services 

F.  NIU-Forum  Conformance 

The  following  pro  forma  outline  of  a  pAP  is  based  on  the  notion  that  a  service-oriented  model 
should  convey  a  sufficient  set  of  properties  of  a  pAP  which  are  aligned  with  standardized  functions 
and  options  (in  the  sense  of  profiles)  to  enable  implementors'  to  succeed  in  having  their  pAP 
derived  products  interoperate. 
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pAP  products  may  be  realized  via  application,  product,  service,  or  combinations  thereof: 


pAP  pro  forma 


1. 


Scope 

1.1  Functional  Model  (Service-oriented) 

1.2  Objective  Criteria 

1.3  Field  of  Application 


2. 


Services 


2.1  Service  Elements/Class 

2.2  Features/Functional  Units 

2.3  Facilities/Interworking 

3.  Profiles 

3.1  Identify 

3.2  Requirements  List  -  pAP 

3.3  Implementors'  Conformance  Statement  (ICS)  pAP 

4.  Conformance  Requirements 

The  root  structural  identifier  for  a  proposed  Application  Profile  (pAP)  is  designated  as 


This  identifier  assumes  the  Application  Environment  definitions  per  the  fUW  treatment  of  xxxxxx 
which  is  the  numeric  lUW  identifier  for  each  ISDN-oriented  application. 

7.4.1.9  Attachment  2  —  pAP  Taxonomy  Overview 

The  pAP  identifier  structure  is  extended  for  user/provider  interplay  and  for  user/network,  or 
user/user  signalling:  The  general  form  of  the  schema  is 

where 

Y    =  the  major  structural  identifier  for  the  general-level 

A    =  the  minor  structural  identifier  for  sub-levels  of  organization  of  the  general-level 

yjX  -  ^6  particular  sub-levels  as  defined  by  A 

if         A    =    S    it  signifies  the  scenario-level  of  interaction  within  a  particular  general-level 


pAP  xxxxxx 


identifier 


if 


A 


s  F  it  signifies  the  functional-level  of  interaction  within  the  scenario-level 
identifier(s) 


if 


A 


s  f  P  It  signifies  the  protocol-level  of  interaction  within  the  functional-level 
identifier  which  is  within  the  scenario-level  (s  0 


finally,  where  A  is 


Physical-level 


.D 
.B 
.E 
.H 


signalling  channel 
basic  rate  access 
primary  rate  mux  channel 
wide-band  rate  access 
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the  schema  shifts  so  that  the  physical-level  identifier  always  occupies  first  position  in  the  schema 
following  the  decimal  point; 


thus  y.xxxx  is 

.D  s  f  p 
.B  s  f  p 
.E  s  f  p 
.Hsfp 

The  latter  identifiers  are  the  most  subordinate  in  the  pAP  Taxonomy  and  are  the  "leaf  of  the  pAP 
Taxonomy  "tree"  of  profiles.  These  leaf  profiles  may  enable  such  details  and  options  like 
attachment  speeds  and  connectors  to  be  registered  by  the  pAP  identifier.  This  specificity  is  for 
further  study. 

pAP  Schema  Overview 

The  pAP  Application  Environment  resides  within  the  Customer  Premises  Environment  unless 
Enhanced  Service  Providers  are  part  of  the  service  interworking. 

The  root  identifier  [pAP  xxxxxx]  and  related  definition  of  the  Application  Context  (signals  from 
the  environment)  is  linked  to  general-level  profile  identifiers  such  as: 

X  user/provider  feature  set 

R  requirement  list 

A  field  of  application 

M  Standards  Promotion  Organizations  (SPO)  profile  selection 

I  ISDN  I.Series  base  standards 

NOTE:  M  profiles  may  encompass  I  profiles 

When  the  general-level  designator  <M>  is  used  in  the  sense  of  the  I  profiles,  it  extends  the  schema 
and  profile  descriptor's  beyond  the  Application  Environment  designators  <X>,  <R>,  and  <A>  to 
the  standardized  ISP  realm  of  profiles. 


When    Y-A       is         M.A      it  depicts  SPO  general-level  profiles 

and  if    A    is    it  is  general-level 

2  1.200  Series 

3  1.300  Series 

4  1.400  Series 

5  1.500  Series 

6  1.600  Series 


The  pAP  AppHcation  resides  on  customer  premise  sub-networks/equipment  /environment.  Such 
CPE  may  be  as  small  as  one  sub-network  or  an  extensive  private  switched  network.  The  structural 
profile  identifiers  for  the  CPE/PSN  backbone  are 

Q  Low  Layer  Compatibility  Functions 
V         High  Layer  Compatibility  Functions 
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7.4.1.10  Attachments 


—  pAP  810004  Tutorial 


Organization 

The  service  framework  depicted  in  table  7-13  [pAP  810004  Service  Overview]  is  structured  in  a 
top-down  manner.  This  structure  incorporates  two  (2)  independent  stacks  of  profile  factors;  the 
field-of-application  stack  and  the  user/provider  feature-set  stack  which  are  separated  by 
Requirements  List  (RL)  identifiers. 

NOTE:  The  profile  factors  "stack"  should  not  necessarily  be  interpreted  as  protocol  stacks. 

The  structure  depicted  in  table  7-13  is  an  integrated  layered- view  of  the  properties  of  the  pAP 
810004  taxonomy  (based  on  Attachment  4),  the  pAP  810004  application  and  the  pAP  810004 
configurator  (basic  and  extended  -  pages  7-39  through  7-48). 

The  middle  column  of  table  7-13  depicts  pAP  810004,  PSN  and  ISDN  requirement  lists  (RL) 
which  are  descriptors  that  are  dependent  on  the  two  (2)  types  of  profile  stacks  mentioned  in  the 
first  paragraph.  This  means  that  particular  realizations  of  pAP  810004  will  encompass  RL  selected 
profile  factors,  services,  features  and  conformance  requirements.  These  RLs  are  directly  related 
to  pAP  810004  profile  attributes  in  contrast  to  generic  properties  of  the  taxonomy,  configurator, 
application,  service,  conformance,  or  features. 

NOTE:  Attachment  1  is  also  an  attempt  to  separate  pAP  810004  intrinsic  matters,  e.g.,  services, 
from  pAP  810004  extrinsic  reahzation  matters,  e.g.  profile  ICSs. 

Reference  Model 

Returning  to  table  7-13,  the  structure  discussed  in  "1.  ORGANIZATION"  above  displays  the 
following  dependencies  whereby  the  application  (pAP  810004),  premises  (CPE,  PSN  and  provider 
support),  and  intervening  networks  (ISDN  WAN)  are  unified  in  terms  of  services,  application, 
function,  features,  reference  configurations  and  everything  short  of  particular  de  facto  logic  and 
implementation  details. 

The  table  7-13  depiction  suggests  the  "pAP  810004"  top-most-level  is  the  "umbrella"  for  all  the 
subsidiary  levels  and  profile  stacks.  It  may  also  imply  that  this  umbrella  dictates  the  contextual 
requirements  and  context/scope  for  the  underlying  levels/sub-networks/networks. 

The  level  below  pAP  810004  is  labelled  "Customer  Premise  Environment"  and  this  level  has  two 
(2)  sub-levels.  The  major  sub-level  directly  addresses  pAP  810004  user/provider  feature  sets  and 
services  that  are  distinguished  from  underlying  PSN  provider  functions,  services,  support  and 
interworking.  The  PSN  sub-level  is  an  intervening  sub-networking  infrastructure  which  visibly  (to 
the  user  sub-level)  connects  the  various  premise  interfaces  to  the  user/application  service  elements 
or  functional  groupings  per  the  reference  configurations. 

The  orientation  of  table  7-13  with  A  =  additional  ~  at  the  left  profile  stack  ~  and  B  =  basic  -  at 
the  right  hand  profile  stack  -  means  that  the  BLLF  and  BHLF  may  be  designated  for  either  the 
ISDN  WAN  and/or  PSN  intervening  networks  whereas  the  ALLF  and  AHLF  are  considered  user- 
premise  extensions.  In  other  words,  "Basic"  is  a  property  of  intervening  provider  facilities,  and 
Basic  facilities  may  only  be  overlaid  by  "Additional"  user  provisioned  resources,  albeit  networked, 
which  are  not  visible  to  intervening  provider  resources. 

Table  7-14  (which  follows)  is  an  attempt  to  consolidate  the  foregoing  pAP  810004  "tutorial" 
notions  by  recasting  table  7-13  in  order  to  depict  a  more  traditional  end-to-end  topology  for  the 
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pAP  810004  application  "umbrella."  Table  7-13  was  designed  to  stress  the  types  of  profile  factors 
needed  to  adequately  describe  pAP  810004  in  generic  terms  -  independent  of  source  or  destination 
realizations. 

Table  7-14  stresses  user/provider  feature  sets  in  the  form  of  high-level  (HLF)  or  low-level  (LLF) 
functions  "stacked"  according  to  basic  (B),  additional  (A)  and  value-added  (V)  service  interworking 
across  the  ISDN  WAN  (the  basic  capability),  the  ISDN  PSN  (the  additional  capability),  and  the 
ISDN  user  functions  (the  value-added  capability). 

Using  table  7-14  and  beginning  at  p.  7-36  [section  7.4.1.5.  pAP  81004  RL  (General-plus  scenario- 
level)],  it  should  be  discemable  what  might  be  the  particular  properties  of  a  point-to-point  pAP 
810004  profile  —  including  configurator  and  conformance  parameters. 
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7.4.1.11  Attachment  4  —  Application  Proflle  (pAP)  Taxonomy 

NOTE:  See  Attachment  2  for  definitions  and  summary  details. 

When  the  general-level  is  distuiguished  using  the  schema  and  scenario-level,  it  enables  "trees"  to  be 
structured  which  have  their  roots  in  the  general-level  identifiers,  for  example: 


when 


y.A 


IS 


and  when  is 

A.S  A.A 

and  when  is 

A.S  A.B 


A.S      it  is  the  scenario-level  of  the  field  of  application 

it  signifies  that  this  profile  is  based  on  PUBLIC  services 


it  signifies  that  this  profile  is  keyed  to  PRIVATE  services 

although  public  wide-area  or  transit  networks  may  underlie  the 

PRIVATE  networks 


and  when  is  it  signifies  that  the  profile  is  a  HYBRID  of  public/private 

A.S  A.C      services,  e.g.,  a  virtual  private  network  (VPN)  using  pubhc  services 

By  extending  the  field  of  application  tree  <A>  to  the  functional-level,  it  enables  several  "branches"  which 
isolate  the  particular  areas  of  the  pAP  810004  Service  Overview  (depicted  in  table  7-13)  as  follows 


when 

is 

it  is 

Y-Ax 

A.Ax 

the  functional-level  of  the  field  of  apphcation  for  PUBLIC 

services 

and  when 

is 

it  is 

A.Ax 

A.Al 

the  user's  CPE  profile  that  is  being  addressed 

A.Ax 

A.A2 

the  provider's  Low  Layer  service  profile  that  is  being  addressed 

A.Ax 

A.A3 

the  provider's  High  Layer  service(s)  profile 

A.Ax 

A.A4 

the  provider's  value-added  (teleservices)  diat  are  distinguished 

A.  Ax 

A.A5 

the  profile  for  the  peer  user  using  PUBLIC  services 

A.Ax 

A.A6 

the  profile  for  multi-peer  users  using  PUBLIC  Services 

NOTE:  peer  (recipient) 

user's  of  PUBLIC 

services  are  virtually  the  same  as  the  originating  user's  profile. 

when 

is 

it  is 

y.Ax 

A.Bx 

the  functional-level  of  the  field  of  application  for  PRIVATE 

services 

and  when 

is 

it  is 

A.Bx 

A.Bl 

the  profile  for  the  user's  (originator)  CPE 

A.Bx 

A.B2 

the  profile  for  the  user's  (originator)  PSN  Low  Layer 

Functions 

A.Bx 

A.B3 

the  profile  for  the  user's  (originator)  PSN  High  Layer 

Functions 

A.Bx 

A.B4 

the  profile  for  the  user's  (originator)  PSN  value-added 

(teleservice) 

A.Bx 

A.B5 

the  proflle  for  the  user's  (originator)  PSN  value-added 

provider,  i.e.,  ESP 

A.Bx 

A.B6 

the  profile  for  the  peer  user  (recipient)  CPE 

A.Bx 

A.B7 

(same  as  A.B2)  for  the  peer  user  PSN  LLFs 

A.Bx 

A.B8 

(same  as  A.B 3)  for  the  peer  user  PSN  HLFs 
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A.Bx  A.B9  (same  as  A.B4)  for  the  peer  user  PSN  VAFs 

A.BX         A.BO  (same  as  A.B5)  tor  the  peer  user  PSN  ESP 

NOTE:  A.B6  thru  A.B9  &  A.BO  apply  to  the  recipient  peer  user 

when  is  it  is 

y.Ax  A.Cx  the  functional-level  of  the  field  of  appUcation  for  HYBRID 

services. 


and  when  is  it  is 


A.Cx 

A.C1 

the  profile  for  the  user's  (originator)  CPE  using  HYBRID 

services 

A.Cx 

A.C2 

the  profile  signifies  a  user's  (originator)  PSN's  use  of 

HYBRID  services 

A.Cx 

A.C3 

the  profile  for  the  user's  VPN  using  PUBLIC  service(s) 

A.Cx 

A.C4 

the  profile  for  the  user's  VPN  using  PRIVATE  service(s) 

A.Cx 

A.C5 

the  profile  for  user's  CENTREX/CO-LAN  using  PUBLIC 

services 

A.Cx 

A.C6 

the  profile  A.C5  but  using  PRIVATE  services 

A.Cx 

A.C7 

the  profile  for  the  peer  (recipient)  user's  CPE  using  HYBRID 

services 

A.Cx 

A.C8 

peer  (recipient)  user's  PSN  use  of  HYBRID  services 

A.Cx 

A.C9 

peer  (recipient)  user's  VPN  using  PRIVATE  services 

A.Cx 

A.CO 

peer  (recipient)  user's  CENTREX/CO-LAN  using  PRIVATE 

services 


NOTE:  peer  (recipient)  user's  of  PUBLIC  services  are  virtually  the  same  as  the  originating  user's  profile 


when  is  it  is 

y.Axx         A.s  f  P  the  protocol-level  of  the  field  of  application 

and  when  it  is 

A.A  f  P  the  protocol-level  of  the  field  of  application  for  PUBLIC 

services 


likewise  are 

A.B  f  P  the  protocol-levels  of  the  field  of  application  for  PRIVATE 

and  HYBRID  and  services  respectively 

A.C  f  P 


is 

it  signifies  the  profile 

A.s  f  P 

A.s  f  1 

for  TEl 

A.S  f  P 

A.s  f  2 

for  TE2 

A.s  f  P 

A.s  f  3 

for  NT2  (S/T) 

A.s  f  P 

A.s  f  4 

for  PSN  (S/T) 

A.s  f  P 

A.s  f  5 

for  PSN  (Nx) 

A.s  f  P 

A.s  f  7 

for  NTl  (T) 

A.s  f  P 

A.s  f  8 

for  peer  user  LLF 

A.s  f  P 

A.s  f  9 

for  peer  user  HLF 

A.s  f  P 

A.s  f  a 

for  peer  provider  LLF 

A.s  f  P 

A.s  f  b 

for  peer  provider  HLF 

A.s  f  P 

A.s  f  c 

for  peer  provider  value-added  (teleservice) 
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NOTE  (1):   when  the  above  profiles  have  an  f=l;  it  signifies  the  user's  (originator)  CPE  use  of  visible 
PUBLIC  services  for  the  intervening  ISDN  WAN 

NOTE  (2):   both  "a"  and  "b"  and  "c"  may  associate  with  the  N^,  reference  point  to  another  ISDN 

NOTE  (3):    for  the  above  profiles,  when  s  =  A  or  B  and  f  =  2,  3,  or  4  respectively  for  the  above  profiles 
p  =  7,  8,  and  9 

NOTE  (4):    A.s  f  6  and  A.s  f  d  are  reserved  for  future  use 


is 

it  signifies  the  profiles  for: 

A.S  f  P 

A.s  f  k 

peer  provider  LLP  and  IWF  is  inside  ISDN 

A.s  f  P 

A.s  f  1 

peer  provider  HLF  and  IWF  is  inside  ISDN 

A.S  f  P 

A.s  f  m 

peer  provider  value-added  (teleservice)  and  IWF  is  inside 

ISDN 

A.s  f  P 

A.s  f  n 

peer  provider  LLF  and  IWF  is  outside  ISDN 

A.s  f  P 

A.s  f  0 

peer  provider  HLF  and  IWF  is  outside  ISDN 

A.s  f  P 

A.s  f  p 

peer  provider  value-added  (teleservice)  and  IWF  is  outside 

When  the  functional-level  (f=2)  then  P=k  at  the  protocol-level  and  N  (sub)  x=IWF  is  (inside)  ISDN 

When  the  functional-level  (f=3)  then  P=l  at  the  protocol-level  and  N  (sub)  x=IWF  is  (inside)  ISDN 

When  the  functional-level  (f=4)  then  P=m  at  the  protocol-level  and  N  (sub)  x=rWF  is  (inside)  ISDN 

When  the  functional-level  is  f=2,  3,  or  4  and  P=n,  o,  or  p  respectively,  then  N  (sub)  x=IWF  is  (outside) 
ISDN  in  each  case 


when  is  it  signifies  the  protocol-level  functions  for 

Y.Axx         A.A  f  P  PUBLIC  Services 

A.B  f  P  PRIVATE  Services 

A.C  f  P  HYBRID  Services 

and  when  it  designates  the  following  protocol-function  categories 

P=H  Connection  Handling 

P=Z  Routing 

P=R  Resources  Handling 

P=S  Supervision 

P=M  Operation  and  Main 

P=I  Interworking 

P=C  Charging 

P=P  L-2/-3  data  unit  handling  (packet  mode) 

For  the  general-level  user/provider  feature  set  the  specific  structural  identifiers  for  the  scenario-level  follow: 

when  is  it  is 

y.A  X.S  the  scenario-level  of  the  user/provider  feature  set 

and  when  is 

X.S  X.U      the  variable  U  signifies  the  number  of  conferencing  users  (peer-to-peer) 
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so  when  it  signifies 

U=l  no  peer  user 

U=2  one  peer  user  i.e.,  point-to-point 

U=3  multi-peer  users 

and  when  is 

X.S  X.R      the  variable  R  signifies  the  number  of  independent  server  domains 

so  when  it  signifies  the 

R=5  server  is  co-incident  with  the  user  CPE 

R=6  servers  are  synmietric  with  peer  users  (point-to-point)  or  multi- 

peer  users 

R=7  server(s)  is  asymmetric  with  peer  users  including  being  in  a 

separate  CPE  from  peer  users  or  multi-peer  users 

and  when  is 

X.S  X.D      the  variable  D  signifies  the  type  of  CPE  domains  that  contain  users 

and/or  servers 

so  when  it  signifies 

D=4  one  domain  which  encompasses  U=l  and  R=5  but  may  have 

multiple  users  in-session  with  their  respective  servers 
D=8  symmetry  of  peer-to-peer  domains  and  encompasses  U=2  or  3 

and  R=6  but  may  signify  multi-in-sessions  between  peer 

domains 

D=9  multi-peer  domains  which  are  symmetric  as  to  users  and 

servers  U=3  and  R=6  but  may  signify  multi-in-sessions 
between  multi-peer  domains 

D=0  multi-peer  domains  which  are  asymmetric  as  to  users  and 

associated  servers  U=3  and  R=7  but  may  also  signify  multi-in- 
sessions  between  multi-peer  users  and  asymmetric  server 
domains 

when  is  it  is 

y.Ax  X.S  F  the  functional-level  of  the  user/provider  feature  set 

when  then 

Functional  Components 

F=i  Hold  Invocation  (disconnect  &  reservation) 

F=f  Retrieve  (reestablish) 

F=n  Notify  (inform,  no  response) 

F=e  Inquire 

F=t  Transfer 

F=j  Join  (multiparty) 

F=a  Adjourn 

F=r  Reroute  (to  alternate  address) 

F=m  Monitor  (watch  for  Event) 

F=x  Restart 

F=s  Split  (from  a  multipart  connection) 
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7.4.1.11.1  Other  Profile  Taxonomy  Matters 


The  capabihties  of  the  user/provider  feature  set  encompasses  the  Application/Service/User  Program  set,  the 
Application  Layer  (7)  Systems  servicing  the  former  set(s),  the  Upper  Layer  Architecture  as  regards  directory 
services,  Security  and  Network  Management,  and  all  Application  Platforms  whether  software  or  hardware 
which  form  the  infrastructure  to  support  the  former  set(s). 

The  pAP  Taxonomy  reserves  a  number  of  structural  identifiers  for  several  types  of  service- 
independent/scenario  profiles  for  user-type  CPE/PSN  environments,  as  follows: 

Identifier  User  Processing  Environment 

X.V  Application  Programs 

X.W  Communications  Processes 

X.Q  Application  Platforms 

The  user/provider  feature  set  may  also  address  the  classical  OS  I  Reference  Model  application-layer. 

when  is  extended  to 

X.s  F  the  OSI  Funcdonal-level 

and  is  a  Provider  Feature  Set 

F=l  Directory 

F=2  Security 

F=3  Management 

F=4  (reserved) 

F=5  File  Transfer 

F=6  Virtual  Terminal 

F=7  Message  Handling 

F=8  Transaction  Processing 

F=9  Remote  Database  Access 

F=0  Job  Transfer  &  Manipulation 

This  enables  the  functional-level  designator  to  distinguish  the  particular  protocol-level  by  the  following 
extension 

when  is  extended  to  the  Protocol-level 

X.sfP  . 

and  when  is 

X.s  5  file  transfer 

then  is  Protocol-identifier 

X.s  5  a  FT  AM  (file  transfer  access  and  management) 

X.s  5  b  FTP  (file  transfer  protocol) 

X.s  5  c  NFS  (network  file  system) 

X.s  5  d  NetBIOS 

X.s  5  e  (reserved) 

when  is  it  is 

y.A  2.S  the  scenario- level  for  the  CCITT  1.200  series  which 

identifies  types  of  services 
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9 

Li 

if 

A  - 

7  Y  Y 

if 

A  - 

"7 

if 

A  — 
A  — 

A,D,L-,. 

if 

A  = 

is  the 

type  of  ISDN  service  described  in  the  CCITT  1.200  series 

types  of  CCITT  1.200  bearer  services,  e.g.,  circuit-mode 

types  of  CCITT  1.200  supplementary  services  of  basic  functional  components 

types  of  CCITT  1.200  signaling  channel  management  services 

types  of  CCITT  1.200  management  services 

NOTE:  ....  =  any  unused  alpha  designator 

when  is  then 

y.A  2.S  CCITT  1.200  services  may  be  registered  at  the 

scenario-level 

thus  is  category 

2.x  circuit-mode 
2.Y  packet-mode 
2.Z  signaling-mode 

or  is  Supplementary  Service  function  (SS) 

2. a  Number  Identification 

2.b  Call  Offering 

2.C  Call  Completion 

2.d  Multiparty 

2.e  Conrununity  of  Interest 

2.f  Charging 

2.g  Additional  Information  Transfer 

when  signifies        Supplementary  Service 

2.a  Number  Identification 

then  is 

2.a  I  Direct  Dialing  In  (DDI) 

2.a  2  Multiple  Subscriber  No.  (MSN) 

2.a  3  Calling  Line  ID  Presentation(  CLIP) 

2.a  4  Calling  Line  ID  Restriction  (CLIR) 

2.a  5  Connected  Line  ID  Presentation  (COLP) 

2.a  6  Connected  Line  ID  Restriction  (COLR) 

2.a  7  Malicious  Call  Identification  (MCI) 

2.a  8  Sub-addressing  (SUB) 

when  signifies        Supplementary  Service 

2.b  Call  Offering 

then  is 

2.b  1  Call  Transfer  (CT) 

2.b  2  Call  Forwarding  Busy  (CFB) 

2.b  3  Call  Forwarding  No  Reply  (CFNR) 

2.b  4  Call  Forwarding  Unconditional  (CFU) 

2.b  5  Call  DeflecUon  (CD) 

2.b  6  Line  Hunting 
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when 
then 


2.C 

2.C  1 
2.C  2 

2.C  3 


signifies 


IS 


Supplementary  Service 
Call  Completion 

Call  Waiting  (CW) 
Call  Hold  (HOLD) 

Completion  of  calls  to  busy  subscribers  (CCDS) 


when 
then 

when 
then 

when 
then 


signifies 


when 
then 

when 

then 


when 


2.d 

2.d  1 
2.d  2 


2.e 

2.e  1 
2.e  2 


2.f 

2.f  1 

2.f  2 
2.f  3 


2.g 
2.g  1 


IS 


signifies 


IS 


signifies 


IS 


signifies 


is 


A  =  A,B,C. 


signifies 


2.A 
2.B 
2.C 
2.D 
2.E 
2.F 


IS 


Supplementary  Service 
Multiparty  SS 

Conference  Calling  (CONF) 
Three  Party  Service  (3PTY) 

Supplementary  Service 
Community  of  Interest  SS 

Closed  User  Group  (CUG) 
Private  Numbering  Plan  (PNP) 

Supplementary  Service 
Charging  SS 

Credit  Card  Calling  (CRED) 
Advice  of  Charge  (AOC) 
Reverse  Charging  (REV) 

Supplementary  Service 
Additional  Information  Transfer 

User-to-User  Signalling  (UUS) 


It  IS 


types  of  CCITT  1.200  signalling  channel  management  services 


.14 


category 
Telephony  (E) 
Telephony  (A) 
Teletex  (A) 
Telefax  4  (A) 
Mixed  Mode  (A) 
Videotex  (A) 

it  is 
3.S 


the  scenario-level  of  the  CCITT  1.300  Series 


and  when  is 
S 


ISDN  reference  points 


"from  1.230: 

(E)  an  essential  access  arrangement  or  bearer  service  category 
(A)  an  additional  access  arrangement  or  bearer  service  category 
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then  is 


S=K  existing  telephony  n/w  or  dedicated 

S=M  specialized  service  provider 

S=N  another  ISDN 

S=P  specialized  n/w  resource 

when  is  it  is 

y.A  4.S  the  scenario-level  of  the  1.400  Series 


NOTE:  previously,  in  these  Appendices,  the  schema  was  extended  to  identify  profiles  encompassing 
channel  types,  B,  D,  E,  and  H  by  shifting  the  schema  at  the  physical-level,  e.g.,  B  s  f  where  "s"  is  also  the 
scenario-level  shifted  right  one  character. 


when 
then 
such  as 


when 
then 

when 


when 
then 

and  when 


y.A 

S(or  s) 

S=R 
S=S 
S=T 
S=U 
S=V 


IS 

may  be 


is 


y.Ax 
S(or  s) 


4.S 


is 


4.B1 
4.B3 
4.B5 


is 


y.Axxx  y.AsF 
signifies 

F 


it  is 


F=l 
F=t 
F=p 
F=c 
F=k 


or 

4.S  4.Bs,  4.Ds,  4.Es,  4.Hs 

ISDN  Reference  Points 


or 


signifies 


4.Bs,  4.Hs 

scenario-level  based  upon  types  of  service 

15 


scenario-types 
Dedicated  (pre-established)  systems  connections 
Permanent  Public  network  connections 
On-demand  Public  network  connections 


at 


the  functional-level 


an  extension  of  the  various  types  of  scenario-level  facilities  with 
designations  for  category  of  connections 


,16 


connection  category 
link 

transmission  system 
purely  circuit  switched 
circuit  switched/ISDN  signalling 
circuit  switched/packet 


'^adapted  from  ECMA  ISPBX  TR/NTW 
"Ibid. 
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when  is 

y.As  F  extended  to  the  functional-level 

and  is  the  connection  categories'^ 

F  Dedicated 

4.B  1  1  physical  link 

4.B  1  t  transmission  systems 

Permanent 

4.B  3  p  purely  circuit  switched 

4.B  3  c  circuit  switched/ISDN  signalling 

4.B  3  k  circuit  switched/packet  switched  signalUng 

On-Demand 

4.B  5  p  purely  circuit  switched 

4.B  5  c  circuit  switched/ISDN  signalling 

4.B  5  k  circuit  switched/packet  switched  signalhng 

when  is 

4.A  s  f  P  extended  to  the  protocol-level'* 

then  Dedicated  Connections  (s=l=physical  link) 
4.B  1  1  1  link  establishment 

4.B  1  1  2  synchronization 
4.B  1  1  3  thruput  delay 

4.B  1  1  4  signalling  u-ansparency 

4.B  1  1  5  failure  performance 

and 

then  is  Dedicated  Connections  (s=t=transmission  system) 

4.B  1  t  1  link  establishment 

4.B  1  t  2  synchronization 
4.B  1  t  3  thruput  delay 

4.B  1  t  4  signalling  transparency 

4.B  1  t  5  failure  performance 

and  so  forth  for 

Permanent    and  On-Demand 

4.B  3  p  4.B  5  p 

4.B  3  c  4.B  5  c 

4.B  3  k  4.B  5  k 


"Ibid. 
''Ibid. 
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NOTE:  If  H  channels  instead  of  B  channels,  then  the  4.Hxxx  schema  is  needed. 


when  is  it  is 

y.A  5.S  the  scenario-level  for  the  CCITT  1.500  series 

and  when  it  signifies 

5.1  Layer  1  interworking  (1.511) 

5.3  Parameter  Exchange  (1.515) 

5.5  ISDN-ISDN  interworking 

5.7  ISDN-Private  Nets  interworking 

when  is 

5.S  F  extended  to  the  functional-level 

and  signifies  interworking  functional  requirements 

5.5 

then  is 

5.5  c  common  channel  signalling 

5.5  X  X.75 

and  when  is 

5.S  f  P  extended  to  the  protocol-level 

then  is 

5.5  c  k  signalling  at  K  reference  point 

5.5  c  n  signalHng  at  N  reference  point 

7.4.1.12  Attachment  5  —  ISDN  RL  Structure 


Table  7-15.  Circuit-mode  bearer  services,  from  1.335 


# 

xfr 

xfr 

xfr 

Estab. 

mode 

rate 

capab. 

of  conn. 

1.1 

ckt 

64 

unres} 

demand 

1.2 

ckt 

64 

unres}  (3) 

reserved 

1.3 

ckt 

64 

unres} 

permanent 

5.1 

ckt 

2x64 

unres 

demand 

5.2 

ckt 

2x64 

unres 

reserved 

5.3 

ckt 

2x64 

unres 

permanent 

(3)  -  during  an  interim  period  some  networks  may  only  offer  restricted  digital  information  transfer  capabiUty 
(i.e.,  an  all-zero  octet  is  not  allowed) 
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Table  7-16.  Unrestricted  digital  connection  types,  from  1.335 


u 
n 

vfr 

xir 

xir 

xir 

struc 

oSiaD. 

laic 

CapaU. 

r\r  r*r\TiT* 
Ui  COllil. 

A.l 

ckt 

64 

unres 

8kHz 

switched 

A  0 
J\.A 

CKl 

Of 

unres 

oKrlZ 

senii-pennaneni 

A  ^ 

r\.J 

CKl 

vr-T 

Ulll  Co 

oKxlz. 

pCliilollClH 

A.IO 

ckt 

2x64 

unres 

8kHz} 

switched 

A.ll 

ckt 

2x64 

unres 

8kHz}  (2) 

semi-permanent 

A.12 

ckt 

2x64 

unres 

8kHz} 

permanent 

(2)  -  RDTD  "Restricted  differential  time  delay" 


1.510  Definition  Relied  Upon  For  A  pAP 

from:     1.510  section  4.2  Definitions  Related  to  the  General  ISDN  Interworking  Configuration 
"Interworking 

Within  the  scope  of  the  1.500  series  of  recommendations,  the  term  interworking  is  used  to  express 
interactions  between  networks,  between  end  systems,  or  between  parts  thereof,  with  the  aim  of 
providing  a  functional  entity  capable  of  supporting  an  end-to-end  communication.  The  interactions 
required  to  provide  a  functional  entity  rely  on  functions  and  on  the  means  to  select  these  functions. 
These  functions  which  include  the  conversion  of  physical  and  electrical  states  and  the  mapping  of 
protocols,  are  referred  to  as  interworking  functions  (IWFs).  An  IWF  may  be  implemented  in  the 
ISDN,  in  the  other  network(s),  at  the  user's  premises,  through  a  third-party  service  provider,  or  in 
some  combination  of  these." 

ISO/IEC  ISP  Taxonomy" 

The  following  extracts^"  are  a  small  portion  of  the  referenced  identifier  structure 
The  ISDN  subnetwork  identifier  structure  for  ISPs  is 


4 

Integrated  Services  Digital  Network 

4  1 

Circuit  Switched  bearer  service  at  S  or  T 

4  1 

1 

B  Channel 

4  1 

1  1 

Semi-permanent  access 

4  1 

1  2 

Demand  Access 

The  LAN  subnetwork  identifier  structure  for  ISPs  is 

5  Local  Area  Networks 

5  1  CSMA/CD 

5  2  Token  Bus 

5  3  Token  Ring 

5  4  FDDI 


'^extract  from  DTR/10000-1 

2°adapted  from  ECMA  ISPBX  TR/NTW 
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7.5  Messaging  and  Answering 
7.5.1  Voice  Messaging  Systems 

This  application  profile  provides  the  descriptions  necessary  to  meet  the  requirements  of  three  NIU-Forum 
user  applications:  "Transparent  Networking  of  Voice  Messaging  Systems"  (860016.0)  (Ref.  [44]);  "Interface 
to  Voice  Messaging  Systems"  (860018.0)  (Ref.  [45]);  and  "Interface  to  Centralized  Voice  Messaging 
System"  (810034.0)  (Ref.  [46]). 

7.5.1.1  User  Description 

Voice  Messaging  Systems  (VMS)  are  becoming  a  fundamental  component  of  corporate  telecommunications 
networks.  ISDN  services  and  products  must  be  capable  of  interfacing  with  these  units  while  providing  as 
good  or  better  service  than  is  available  today.  North  American  ISDN  User's  Forum  "users"  have  submitted 
ISDN  applications  requiring  an  ISDN  application  that  provides  the  capability  for  integrating  VMS  with 
ISDN  service. 

VMS  allows  automatic  telephone  coverage  without  the  need  for  individual  station  equipment  (i.e.,  answering 
machines)  or  full-time  monitoring  by  other  personnel  (i.e.,  secretaries).  VMS  can  also  provide  the 
functionality  for  voice  mail  where  callers  may  leave  voice  messages  for  others  without  directly  calling  the 
others.  A  third  function  for  VMS  is  call  prompting  which  provides  callers  with  additional  information 
before  selecting  various  options  processed  by  the  VMS.  Call  Prompting  goes  beyond  the  scope  of  this 
document. 

Calls  to  VMS  subscribers'  telephones  are  redirected  by  the  ISDN  switch  (Telco  central  offices  or  PBXs) 
to  the  VMS  with  sufficient  information  for  the  VMS  to  efficiently  handle  the  call.  Calls  can  be  redirected 
several  ways  -  the  VMS  subscriber  can  "call  forward  all  calls"  to  the  VMS  (CPU  -  Call  Forward 
Unconditional);  calls  with  no  answer  can  be  call  forwarded  (CFNR  -  Call  Forward  No  Reply);  and  calls  to 
a  busy  telephone  can  be  call  forwarded  (CFB  -  Call  Forward  Busy).  In  the  case  of  voice  mail,  the  VMS 
subscriber  directly  calls  the  VMS  to  leave  messages  rather  than  being  call  forwarded  by  the  ISDN  switch. 
Calling  parties  select  options  provided  by  call  prompting  (i.e.,  redirecting  to  another  telephone  by  the  ISDN 
switch,  redirected  to  another  VMS  subscriber's  mailbox  by  the  VMS). 

The  VMS  must  be  able  to  receive  and  store  the  message  in  the  appropriate  VMS  subscriber's  mailbox  and 
in  turn  alert  the  VMS  subscriber  that  a  message  is  waiting  by  activating  some  type  of  message  waiting 
indicator  (MWI)  (i.e.,  lamp,  display,  interrupted  dial  tone).  Future  functions  may  allow  the  VMS  to  include 
the  calling  I.D.  or  name,  an  urgent  indication,  etc.,  in  the  message  waiting  notification.  The  VMS  should 
be  capable  of  serving  both  ISDN  and  non-ISDN  subscribers. 

Figure  7-28  shows  an  overview  of  the  user  physical  environment  for  voice  messaging  and  answering 
applications.  It  includes  one  or  more  ISDN  switches  networked  together,  one  or  more  VMSs  networked 
together,  non-VMS  calling  parties  (analog,  digital  and  ISDN)  and  VMS  subscribers  (analog,  digital  and 
ISDN).  The  BRI  and  PRI  ISDN  interfaces  should  support  this  VMS  Application  Profile. 

This  application  profile  provides  the  descriptions  necessary  to  meet  the  requirements  of  three  NIU-Forum 
user  appIicaUons:  "Transparent  Networking  of  Voice  Messaging  Systems"  (860016.0);  "Interface  to  Voice 
Messaging  Systems"  (860018.0);  and  "Interface  to  Centralized  Voice  Messaging  System"  (810034.0).  The 
profile  also  refers  to  "Secure  Voice  Mail"  (050015.0)  (Ref.  [47]),  "Secure  E-Mail"  (050014.0)  (Ref.  [48]) 
and  "Secure  Facsimile  Transmission  through  ISDN"  (050016.0)  (Ref.  [49])  although  the  security  aspects 
are  not  included  in  this  profile. 
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7.5.1.2  ISDN  Application  Breakdown 

The  above  user  description  is  divided  into  three  distinct  cases  based  on  different  interactions  between  the 
ISDN  switch  and  the  VMS  user.  The  three  cases,  Call  Answering,  Call  Answering  with  Call  Transfer  to 
an  Attendant,  and  Direct  Access  to  Voice  Mail  are  depicted  in  figure  7-29.  The  following  describes  the 
different  interactions  required  between  the  ISDN  switch,  the  VMS,  the  calling  party  and  the  called  party. 

7.5.1.2.1  Call  Answering 

The  VMS  function  allows  automatic  telephone  coverage  without  the  need  for  individual  station  equipment 
(i.e.,  answering  machines)  or  for  full-time  monitoring  by  other  personnel.  Calls  to  the  VMS  subscriber's 
telephone  are  redirected  by  the  ISDN  switch  to  the  VMS  with  sufficient  information  for  the  VMS  to  handle 
the  calls.  The  calls  may  be  redirected  several  ways:  call  forward  all  calls  to  the  VMS;  call  forward  calls 
encountering  a  busy  status;  call  forward  no  response  calls.  Calls  may  also  be  call  transferred  to  a  VMS 
subscriber  mailbox  by  a  third  party  such  as  a  secretary  or  call  attendant  who  received  the  initial  call. 

7.5.1.2.2  Call  Answering  With  Call  Transfer  To  An  Attendant  Or  Pager  Notification 

This  is  similar  to  the  above  description  when  the  initial  call  is  call  forwarded  to  the  VMS.  The  VMS  has 
the  additional  feature  allowing  the  calling  party  the  ability  to  transfer  out  of  the  VMS  back  to  an 
attendant/secretary's  telephone.  The  VMS  may  also  allow  the  calling  party  the  ability  to  page  the  desired 
person.  These  capabilities  are  used  for  urgent  or  emergency  calls  when  a  message  is  not  sufficient  or 
tim.ely.  The  caUing  party  may  also  transfer  out  of  the  VMS  to  make  other  calls. 

7.5.1.2.3  Direct  Access  To  Voice  Mail 

A  VMS  subscriber  may  call  the  VMS  directly  to  leave  messages  for  one  or  more  VMS  subscribers  or  other 
VMS  subscribers  if  networked  together  with  the  initial  subscriber's  VMS.  The  voice  mail  functionalities 
are  analogous  to  E-mail  and  include  the  ability  to  edit,  broadcast,  save,  delete  and  reu-ieve  messages,  etc. 

7.5.1.3  Service  Logic 

Voice  Messaging  and  Answering  Applications  involve  combinations  of  three  different  processes:  VMS 
Subscriber  Access,  VMS  Subscriber  Notification  and  VMS  Subscriber  Message  Retrieval.  Section  7.5.1.4, 
Messaging  and  Answering  Application  Processes,  describes  each  of  these  processes  in  more  detail.  In  a 
single  VMS  system,  the  calling  party  accesses  the  VMS  subscriber's  mailbox  and  leaves  a  message.  The 
subscriber  is  notified  that  a  message  is  waiting  and  then  retrieves  the  message.  The  VMS  subscriber's 
notification  is  then  canceled.  This  flow  is  shown  in  figure  7-30.  The  flow  is  basically  the  same  in  a 
multiple  VMS  environment,  except  that  after  the  calling  party  leaves  a  message,  the  first  VMS  sends  the 
message  to  the  VMS  subscriber's  mailbox  on  tlie  second  VMS  through  message  networking.  The  multiple 
VMS  messaging  and  answering  applications  flow  is  shown  in  figure  7-31. 

7.5.1.4  Messaging  And  Answering  Application  Process 

The  following  describes  the  three  basic  Messaging  and  Answering  application  processes  in  more  detail: 
Subscriber  Access,  Subscriber  Notification,  and  Subscriber  Message  Retrieval. 

7.5.1.4.1  Subscriber  Access 

Subscriber  access  is  the  first  stage  in  Messaging  and  Answering  application  process. 
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7.5.1.4.2  Application  Process  Description 


Subscriber  access  includes  the  steps  to  connect  the  calling  party  to  the  VMS  so  that  a  message  may  be 
recorded  and  deposited  in  the  called  party's  VMS  subscriber  mailbox.  It  allows  the  calling  party  to  transfer 
out  of  the  VMS  when  desired.  This  occurs  when  the  calling  party  desires  to  speak  to  an  attendant  or 
secretary.  When  this  happens,  the  calling  party  has  left  the  Messaging  and  Answering  applications  process. 
Sometimes  a  secretary  or  attendant  may  transfer  a  calling  party  to  the  VMS  to  leave  a  recorded  message 
for  the  called  party.  In  this  case,  the  process  treats  the  call  exactly  as  if  the  calling  party  called  directly. 

The  Message  Networking  subprocess  is  optional  and  used  only  when  multiple  VMSs  need  to  communicate 
with  each  other  using  the  ISDN  network.  This  situation  occurs  in  campus  environments  with  multiple 
VMSs  and  one  ISDN  switch  or  in  inter-location  environments  with  multiple  VMSs  and  multiple  ISDN 
switches.  The  networking  communication  occurs  when  one  VMS  needs  to  deliver  messages  to  another 
VMS.  The  objective  is  that  multiple  VMSs  should  appear  as  one  large  VMS  to  the  VMS  subscribers. 

7.5.1.4.2.1  Subscriber  Access  Process  Alternative  Architectures 

A  calling  party  may  be  forwarded  or  transferred  to  the  VMS  using  one  of  several  different  service  elements 
including  Call  Forwarding  Busy  (CFB),  Call  Forwarding  Variable  (CFV),  or  Call  Forwarding  No  Answer 
(CVN).  The  particular  service  element  used  to  establish  connectivity  is  not  critical  to  the  Subscriber  Access 
stage.  What  is  critical  is  that  the  calling  party  is  connected  to  the  VMS  with  an  opportunity  to  leave  a  voice 
message  in  the  VMS  subscriber's  mailbox. 

Figures  7-32,  7-35,  7-38,  7-41,  and  7-43  show  the  specific  physical  environment  for  each  of  the  three  cases 
described  in  section  7.5.1.2.  The  various  steps  in  each  case  are  simplified  to  show  typical  interactions 
between  the  calhng  party  and  the  VMS.  In  the  real  world  this  interaction  might  be  more  complicated.  For 
example,  a  VMS  subscriber  might  be  the  calling  party  wishing  to  leave  another  subscriber  a  message  and 
retrieving  a  message  on  the  single  call. 

In  7-32,  7-35,  7-38,  and  7-41,  Subscriber  Access  is  defined  so  that  all  the  VMS  subscribers  are  connected 
to  a  single  ISDN  switch  or  PBX.  In  the  real  world,  however.  Messaging  and  Answering  applications  will 
also  occur  in  multiple  ISDN  switched  networks. 

The  Message  Networking  physical  environment  necessary  to  have  one  VMS  communicate  with  a  second 
VMS  is  shown  in  figure  7-43.  This  environment  will  require  multiple  VMSs  (possible  from  different 
manufacturers)  to  forward  voice  mail  over  ISDN  networks  in  a  standard  and  uniform  way. 

7.5.1.4.2.2  Information  Flow  Diagrams 

Information  Flow  Diagrams  show  the  specific  service  elements  necessary  to  complete  the  Messaging  and 
Answering  application  process.  For  example,  the  Information  Flow  Diagram  for  Call  Answering  -  No 
Answer  is  shown  in  figure  7-33.  The  Diagram  for  Call  Forwarding  -  Busy  or  Variable  is  shown  in  figure 
7-34.  The  remaining  Diagrams  for  Subscriber  Access  are  shown  in  figures  7-36,  7-37,  7-39,  7-40,  7-42  and 
7-44. 

7.5.1.4.2.3  Protocol  Requirements  and  Application  Service  Element  Description 

The  supplementary  services,  messages  and  protocol  elements  described  below  are  only  those  required  by 
this  profile.  Other  messages  and  protocol  elements  are  not  discussed  if  they  are  not  used  by  the  application 
being  described,  even  though  they  may  be  required  for  other  reasons,  such  as  routing  of  the  call.  See  figures 
7-32,  7-35,  7-38,  7-41,  and  7-43.  Please  note  that  the  required  ANSI  and  NIUF  documents  will  be  suppUed 
as  they  become  available.  NIU.xxx  implies  that  the  Messaging  and  Answering  Profile  team  is  requesting 
the  Supplementary  Services  Working  Group  to  create  that  particular  document. 
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Call  Setup 


The  call  setup  process  is  described  in  NIU.301  (Appendix  A)  and  NIU.302  (Appendix  B).  This  process  is 
used  to  establish  the  initial  call. 

Call  Forwarding  With  Associated  Data 

The  Call  Forwarding  supplementary  service  is  defined  in  Tl.xxx  and  NIU.xxx.  This  service  supplies  the 
VMS  with  the  subscriber's  DN  which  will  be  used  to  deposit  the  message  in  the  proper  mailbox. 

Call  Setup  (direct) 

The  call  setup  process  is  described  in  NIU.301  and  NIU.302.  This  process  is  used  to  setup  a  call  directly 
to  the  VMS. 

Call  Delivery  With  Associated  Data 

The  call  (i.e.,  voice  message)  is  delivered  to  the  VMS  using  NIU.301  or  NrU.302.  These  protocols  supply 
the  VMS  with  the  subscriber's  DN  which  will  be  used  to  deposit  the  message  in  the  proper  mailbox. 

Connectivity  to  Called  Subscriber's  Mailbox 

Current  protocols  exist  to  supply  connectivity  between  the  switch  and  the  VMS;  however,  when  connecting 
the  VMS  and  the  Switch  via  ISDN,  the  NIU.301  and  NIU.302  documents  are  required. 

Call  Transfer  With  Associated  Data 

The  Call  Transfer  supplementary  service  is  detined  in  Tl.xxx  and  NIU.xxx.  These  services  supply  the  VMS 
with  the  subscriber's  DN  which  will  be  used  to  deposit  the  message  in  the  proper  mailbox. 

Call  Termination 

NIU.301  and  NIU.302  describe  the  necessary  terminating  procedures  required  to  release  the  connection 
between  the  VMS  and  the  Switch. 

Call  Termination  Outside  VMS/Switch 

NrU.301  and  NIU.302  describe  the  necessary  terminating  procedures  required  to  release  the  connection 
between  the  calling  party  and  the  Switch. 

VMS  Interoperability 

The  VMS  Interoperability  requirements  are  defined  in  Tl.xxx  and  NIU.xxx.  VMS  Interoperability  is  critical 
in  defining  how  VMSs  communicate  with  one  another. 

7.5.1.4.2.4  Conformance  Tests 

The  conformance  tests  to  support  this  profile  have  not  been  written.  This  data  will  be  supplied  at  a  later 
date. 
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7.5.1.4.3  Subscriber  Notification 

The  VMS  Subscriber  Notification  is  tlie  second  stage  in  the  Message  and  Answering  application  process. 

7.5.1.4.3.1  Application  Process  Description 

The  VMS  has  the  capability  to  control  the  message  waiting  indicator  (MWI)  provided  to  the  VMS 
subscriber  via  the  ISDN  switch.  The  MWI  informs  the  VMS  subscriber  the  status  of  recorded  messages 
in  the  subscriber's  mailbox.  For  an  ISDN  subscriber,  the  MWI  may  be  a  lamp,  display  or  audible  indication 
(e.g.,  interrupted  dial-tone).  For  non-ISDN  subscribers,  the  MWI  should  be  in  the  form  of  an  audible 
indication  or  visual  indication  supplied  by  the  switch. 

The  MWI  should  be  able  to  notify  VMS  subscribers  when  they  have  messages  waiting  and  when  there  are 
no  messages  waiting.  The  terms  activated  and  deactivated  indicate  which  notification  is  being  provided. 

7.5.1.4.3.2  Subscriber  Notification  Process  Alternative  Architectures 

VMS  subscriber  notification  process  is  invoked  whenever  the  VMS  causes  the  ISDN  network  to  "activate" 
or  "deactivate"  the  VMS  subscriber's  message  waiting  indicator.  Typically,  the  MWI  is  activated  when  a 
message  is  waiting  and  deactivated  when  no  messages  remain.  However,  the  VMS  may  activate  or 
deactivate  the  MWI  at  other  times,  such  as  during  an  error  recovery  process  or  if  redundant  MWI  activation 
or  deactivation  messages  are  sent. 

In  typical  existing  implementations,  all  of  the  VMS's  subscribers  are  connected  to  a  single  ISDN  switch 
or  PBX.  The  Messaging  and  Answering  application  physical  environment  for  subscriber  notification  when 
the  VMS  subscribers  and  the  VMS  are  connected  to  a  single  ISDN  switch,  is  shown  in  figure  7-45. 
However,  when  a  number  of  users  in  many  locations  subscribe  to  a  single,  centrally  located  VMS,  then 
multiple  ISDN  switches  are  involved.  The  VMS  first  notifies  the  ISDN  switch  it  is  directly  connected  to 
tell  the  next  switch  (or  the  third,  etc.)  connected  to  the  VMS  subscriber  to  activate  the  VMS  subscriber's 
MWI.  This  environment  is  shown  in  figure  7-47.  The  same  steps  occur  in  both  environments  when  the 
VMS  notifies  the  ISDN  switch(s)  to  deactivate  the  subscriber's  MWI.  These  environments  are  shown  in 
figures  7-49  and  7-51. 

7.5.1.4.3.3  Information  Flow  Diagrams 

The  Information  Flow  Diagrams  for  VMS  subscriber  notification  are  shown  in  figures  7-46,  7-48,  7-50  and 
7-52. 

7.5.1.4.3.4  Protocol  Requirements  and  Application  Service  Element  Description 

The  supplementary  service.  Message  Waiting  Indicator  Control  and  Notification,  will  be  the  primary 
requirement  specification  to  implement  the  following  sub-sections.  See  figures  7-45  through  7-51.  Please 
note  tliat  tlie  required  Tl.xxx  and  NIU.xxx  will  be  supplied  as  they  become  available.  NIU.xxx  implies  that 
the  Messaging  and  Answering  Profile  team  is  requesting  the  Supplementary  Services  Working  Group  to 
create  the  Message  Waiting  Indicator  Control  and  Notification  document. 

Message  Waiting  Indicator  Control  Activation  (VMS  to  Switch) 

The  requirements  for  MWI  Control  activation  between  the  VMS  and  the  Switch  are  in  Tl.xxx  and 
NIU.XXX. 
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MWI  Activation  (Switch  to  Terminal  Equipment) 

The  requirements  for  MWI  activation  are  in  Tl.xxx  and  NIU.XXX. 

MWI  Control  Deactivation  (VMS  to  Switch) 

The  requirements  for  MWI  Control  deactivation  between  the  VMS  and  the  Switch  are  in  Tl.xxx  and 
NIU.XXX. 

MWI  Deactivation  (Switch  to  Terminal  Equipment) 

The  requirements  for  MWI  deactivation  are  in  Tl.xxx  and  NIU.XXX. 

Network  Signaling  Requirements 

The  requirements  for  MWI  Network  signaling  are  in  Tl.xxx  and  NIU.XXX.  These  requirements  are 
necessary  for  controlling  the  MWI  for  a  centralized  VMS.  The  TCAP  messages  are  sent  within  the  network 
to  control  the  MWI. 

7.5.1.4.3.5  Conformance  Tests 

The  conformance  tests  to  support  this  profile  have  not  been  written.  This  data  will  be  supplied  at  a  later 
date. 

7.5.1.4.4  Subscriber  Retrieval 

The  VMS  Subscriber  Retrieval  process  is  the  third  stage  in  the  Message  and  Answering  apphcation  process. 

7.5.1.4.4.1  Application  Process  Description 

When  the  VMS  subscribers  message  waiting  indicators  show  waiting  messages  the  VMS  subscribers  access 
the  VMS  directly  to  retrieve  and  process  their  voice  messages.  Once  the  retrieval  stage  is  completed,  the 
VMS  must  notify  the  ISDN  switch  to  deactivate  the  MWI. 

7.5.1.4.4.2  Called  Subscriber  Retrieval  Alternative  Architectures 

A  VMS  subscriber  may  be  connected  to  the  VMS  by  several  different  service  elements,  such  as  Direct  Call 
Set-up,  Call  Forwarding,  Call  Transfer,  etc.  The  particular  service  element  used  to  establish  connectivity 
is  not  critical  to  the  VMS  subscriber  retrieval  stage.  It  is  important  that  the  VMS  subscribers  be  connected 
to  the  VMS  with  an  opportunity  to  retrieve  the  messages  from  their  mailboxes. 

The  Message  and  Answering  physical  environments  for  when  the  VMS  subscribers  and  VMS  are  connected 
to  the  same  ISDN  switch  is  shown  in  figure  7-53. 

7.5.1.4.4.3  Information  Flow  Diagrams 

The  Information  Flow  from  VMS  subscriber  access  into  a  VMS  is  shown  in  figure  7-54. 
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7.5.1.4.4.4  Protocol  Requirements  and  Application  Service  Element  Description 

The  protocol  requirements  and  application  service  elements  necessary  for  subscriber  retrieval  are  a  subset 
of  those  in  section  7.5.1.4.2.3. 

Call  Setup  (Direct) 

See  section  7.5.1.4.2.3. 

Call  Delivery  With  Associated  Data 

See  section  7.5.1.4.2.3. 

Connectivity  to  Called  Subscriber's  Mailbox 

See  section  7.5.1.4.2.3. 

Call  Termination 

See  section  7.5.1.4.2.3. 

7.5.1.4.4.5  Conformance  Tests 

The  conformance  tests  to  support  this  profile  have  not  been  written.  This  data  will  be  supplied  at  a  later 
date. 

7.5.1.4.5  Summary  of  MA  processes 
See  Table  7-17. 
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7.6  Future  Bandwidth  Negotiation 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Bandwidth  Negotiation. 
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7.7  Network  Management/ISDN  Administration 

Editor's  Note:  This  section  is  reserved  for  future  agreements  on  Network  Management/ISDN 
Administration. 

7.7.1  ISDN  Station  Event  Recording  (ISER) 

7.7.1.1  Basic  Description 

ISDN  (and  non-ISDN)  users  require  detailed  records  of  station  events  in  a  universal  format  independent 
of  the  switching  element. 

The  expected  benefits  of  this  application  are: 

•  Standard  format  for  ISDN  station  event  data 

•  Standard  protocol  for  data  ttansfer 

•  User-selectable  interface 

•  Flexibility  with  regard  to  the  data  transferred 

•  Improved  ability  to  process  the  data 

This  application  (Ref.  [50])  involves  standardizing  the  information  content  and  format  of  information 
provided  to  the  user  as  well  as  providing  a  standard  interface  from  which  the  user  obtains  the  data. 
This  interface  is  defined  as  "A"  in  figure  7-55. 

The  user  has  the  ability  to  retrieve  the  data  in  a  uniform  manner.  The  retrieval  method  preserves  the 
integrity  and  completeness  of  the  data. 

This  application  involves  primarily  the  accounting  management  functional  area  of  OSI  network 
management. 

The  intention  of  this  application  is  to  be  able  to  provide  data  for  an  event  from  its  originating  station  to 
its  terminating  station  including  all  intermediate  switching  nodes  as  required  by  the  ISER  user. 

7.7.1.2  Functional  Requirements 

The  ISDN  Station  Event  Recording  Module  (ISERM),  is  a  managed  object  for  formatting,  recording, 
and  retrieving  user  data  from  the  ISDN  environment.  The  ISERM  includes  the  following  attributes: 

•  Standard  Interface  Protocol 

•  ISER  Configuration  Profile 

•  Standard  ISER  Data  Delivery  Format 

-  Minimum  Data  Set  for  Event  Recorded  Information 
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7.7.1.2.1  Standard  Interface  Protocol 

A  standard  interface  is  provided  to  allow  the  user  device  (OSI  agent)  to  establish  a  connection  to  the 
ISDN  environment  for  ISER  activities.  Any  such  interface  has  the  capability  to  establish  a  2-way 
communications  link  (full  duplex)  between  the  user  device  and  the  ISDN  environment  using  managed 
objects. 

This  connection  uses  a  standard  protocol  which  faciUtates  the  orderly  and  efficient  transfer  of  ISER  data 
from  the  ISDN  environment  to  the  user's  device(s).  This  protocol  provides  the  following  minknum 
capabilities: 

•  The  ability  to  request  the  ISERM  to  perform  the  transfer  of  ISER  data  from  the  ISDN 
environment  to  user's  devices. 

•  The  ability  to  access  an  ISER  Standard  Configuration  profile  for  the  purpose  of  reviewing 
and  changing  its  current  information. 

•  The  ability  to  establish  and  maintain  a  secure  user  environment  for  the  purpose  of  restricting 
control  and  access  to  the  ISERM. 

In  order  to  support  this  application,  the  protocol  suites  shown  in  figures  7-56  and  7-57  are  to  be 
considered  as  suggested  implementation  alternatives. 

ISER  implementation  should  not  preclude  future  TP  (Distributed  Transaction  Processing)  protocol 
support  for  this  application.  See  figures  7-58  and  7-59  for  suggested  implementation  alternatives  once 
TP  has  been  made  to  accepted  standard. 

7.7.1.2.2  ISER  Configuration  Profile 

A  configuration  profile  will  exist  in  the  ISDN  environment  for  each  user  for  the  purpose  of  controlling 
and  downloading  ISER  data  to  the  user's  external  device(s).  This  configuration  profile  is  the  minimum 
subset  of  the  management  data  base  for  the  managed  object,  ISERM,  and  its  processes  required  to 
interact  with  the  external  device(s). 
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Figure  7-56.  FTAM  NON-ISDN  Protocol  Usage  for  Universal  ISER  Application. 
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Figure  7-57.  FTAM  ISDN  Protocol  Usage  for  Universal  ISER  Application. 
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Figure  7-58.  TP  Non-ISDN  Protocol  Usage  for  Universal  ISER  Application. 


Application 


Presentation 


Session 


Transport 


Network 


Data  Link 


Physical 


ISO  8571 


TP 


TPSE 


ACSE 


CCR 


ISO  8822-25 
Kernel 


ISO  8326,  8327 
Kernel 


ISO  8602,  8072,  8073 


T1.607,  T1.608,  T1.610/ 
NIU  301,  NIU  302,  NIU  320 


T1.602/NIU  210 


T1.601,  T1.605/NIU  101,  NIU  105 


Figure  7-59.  TP  ISDN  Protocol  Usage  for  Universal  ISER  Application. 
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At  a  minimum,  this  profile  allows: 


7.7.1.2.2.1  Event  record  selection  based  on: 

•  Event  classes 

-  Station-to-station 

-  Message  network  access 

-  Private  facility  access 

•  Event  types 

-  All  attempts 

-  All  completions 

-  Answered  only 

•  Event  category 

-  Originating 

-  Terminating 

7.7.1.2.2.2  Access  control  based  on: 

•  Set  of  actions 

-  Interface  protocol 

-  Interface  speed 

•  Set  of  constraints 

-  Authorized  users 


7.7.1.2.2.3  User  identification  based  on: 

•  Unique  identification  assigned  to  each  ISER  user  (User  Identifier  in  ISER  record) 
7.7.1.2.3  Standard  ISER  Data  Delivery  Format 

A  standard  deHvery  format  is  established  that  allows  the  user  to  receive  ISER  data  in  a  form  that  is 
consistent  in  format  and  content.  An  implementation  agreement  should  be  established  for  the  specific 
contents  of  each  data  segment  and  the  grouping  of  those  segments  into  standard  ISER  records. 

The  following  is  the  required  minimum  set  of  event  data  that  should  be  included,  as  applicable,  for  an 
event. 


-  Numbers  of  simultaneous  users 

-  Restticted  actions 


Item 


Description 


Network  Element  Identifier 


Switch  Identification 


User  Identifier 


User  Identification 


Group  Identifier 


Customer  Identifier 


Record  Type 


Identifies  the  Event  Record  Content  and  Format, 
e.g.,  Originating,  Terminating,  etc. 
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Item 


Description 


Service  Identification 
Event  Type 
Event  Category 
Event  Class 

Originating  Number 

Route  Information 

Originating  Type 

Originating  Trunk 
Group/Member 

Call  Complete  Code 

Facility  Restriction  Level 
Terminating  Number 
SPED 

Terminating  Type 

Terminating  Trunk 
Group/Member 

Event  Start  Time 
(Time  of  Day) 

Call  Duration 

Digits  Dialed 

Digits  Outpulsed 

Authorization  Code 

Account  Code 

Volume  of  Packet  Data 
Both  In/Out 

Network  User  Identification 
(NUI) 

Billing  Number 


Type  of  Service  Provided: 
Circuit-Switched  Voice  (CSV), 
Circuit-Switched  Data  (CSD), 
Packet-Switched  Data  (PSD) 

Telephone  Number  plus  Routing  Digits  (DNIC,  etc.) 

ARS  (Automatic  Route  Selection)  Pattern  Group 

Station,  Attendant,  Trunk  (Virtual  and  Physical), 
Offnet  Line,  Offtiet  Trunk,  Foreign  Exchange,  other 
Onnet/Offtiet,  Shared  Directory  Number 

Private  Trunk  Group  and  Member  Number 

Answered,  Unanswered,  Busy,  Abandoned, 
Attendant  Extended 

Privilege  Class  Level 

Telephone  Number  (DNIC,  etc.) 

Station  Profile  Identification 

Station,  Attendant,  Trunk,  (Virtual  and  Physical), 
Offnet  Line,  Offnet  Trunk,  Foreign  Exchange,  other 
Onnet/Offtiet,  Shared  Directory  Number 

Private  Trunk  Group  and  Member  Number 

Julian  Date,  Hours,  Minutes,  Seconds,  and  Tenths 
Answer  Time  if  Answered,  End  of  Dial  Time  if 
Unanswered 

Usage  Time  in  Seconds  and  Tenths 

Digits  actually  Dialed  by  User 

Digits  actually  Transmitted  over  the  Network 

Used  to  Define  Privilege  Level 

Used  to  assign  Charges  to  a  particular  Account 

Number  of  octets  Transferred 

Identify  Users  for  Billing  Purposes 

To  cause  Charging  and  Acceptance  for  Packet  Calls, 
if  Subscribed 
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Item 


Description 


Service  Identification 
Event  Type 
Event  Category 
Event  Class 

Originating  Number 

Route  Information 

Originating  Type 

Originating  Trunk 
Group/Member 

Call  Complete  Code 

Facility  Restriction  Level 
Terminating  Number 
SPID 

Terminating  Type 

Terminating  Trunk 
Group/Member 

Event  Start  Time 
(Time  of  Day) 

Call  Duration 

Digits  Dialed 

Digits  Outpulsed 

Authorization  Code 

Account  Code 

Volume  of  Packet  Data 
Both  In/Out 

Network  User  Identification 
(NUI) 

Billing  Number 


Type  of  Service  Provided: 
Circuit-Switched  Voice  (CSV), 
Circuit-Switched  Data  (CSD), 
Packet-Switched  Data  (PSD) 

Telephone  Number  plus  Routing  Digits  (DNIC,  etc.) 

ARS  (Automatic  Route  Selection)  Pattern  Group 

Station,  Attendant,  Trunk  (Virtual  and  Physical), 
Offnet  Line,  Offnet  Trunk,  Foreign  Exchange,  other 
Onnet/Offnet,  Shared  Directory  Number 

Private  Trunk  Group  and  Member  Number 

Answered,  Unanswered,  Busy,  Abandoned, 
Attendant  Extended 

Privilege  Class  Level 

Telephone  Number  (DNIC,  etc.) 

Station  Profile  Identification 

Station,  Attendant,  Trunk,  (Virtual  and  Physical), 
Offnet  Line,  Offnet  Trunk,  Foreign  Exchange,  other 
Onnet/Offnet,  Shared  Directory  Number 

Private  Trunk  Group  and  Member  Number 

Julian  Date,  Hours,  Minutes,  Seconds,  and  Tenths 
Answer  Time  if  Answered,  End  of  Dial  Time  if 
Unanswered 

Usage  Time  in  Seconds  and  Tenths 

Digits  actually  Dialed  by  User 

Digits  actually  Transmitted  over  the  Network 

Used  to  Define  Privilege  Level 

Used  to  assign  Charges  to  a  particular  Account 

Number  of  octets  Transferred 

Identify  Users  for  Billing  Purposes 

To  cause  Charging  and  Acceptance  for  Packet  Calls, 
if  Subscribed 


NIU-Forum  Agreements  On  ISDN 


8  References 


8.1  ANS  documents 

[I]  ANS  Tl.l  1 1-1988,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  Message  Transfer 
Part  (MTP). 

[2]  ANS  Tl.l  12-1988,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  Signalling 
Connection  Control  Part  (SCCP). 

[3]  ANS  Tl.l  13-1988,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  ISDN  User  Part 
(ISUP). 

[4]  ANS  Tl.l  14-1988,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  Transactions 
Capability  Application  Part  (TCAP). 

[5]  ANS  Tl. 115-1989,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  Monitoring  and 
Measurements. 

[6]  ANS  Tl. 116-1989,  Telecommunications  —  Signalling  System  Number  7  (SS7)  —  Operations, 
Maintenance,  Administration  and  Provisioning  (OMAP). 

[7]        ANS  Tl.216-1991,  ISDN  Management  —  Basic  Rate  Physical  Layer. 

[8]        ANS  Tl  .2 17- 1991,  ISDN  Management  —  Primary  Rate  Physical  Layer. 

[9]        ANS  Tl.218-1991,  ISDN  Management  —  Data  Link  and  Network  Layers. 

[10]  ANS  Tl. 403-1989,  Telecommunications  —  Carrier  to  Customer  Installation  —  DSI  Metallic 
Interface. 

[I I]  ANS  Tl  .408-1990,  Telecommunications  —  Integrated  Services  Digital  Network  ( ISDN)  —  Primary 
Rate  —  Customer  Installation  Metallic  Interfaces  —  Layer  I  Specification. 

[12]  ANS  Tl.601-1988,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Basic 
Access  Interface  for  Use  on  Metallic  Loops  for  Application  on  the  Network  Side  of  the  NT-Layer 
I  Specification. 

[13]  ANS  Tl.602-1989,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Data- 
Link  Layer  Signalling  Specification  for  Application  at  the  User-Network  Interface. 

[14]  ANS  Tl. 603-1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  — Minimal 
Set  of  Bearer  Services  for  the  Primary  Rate  Interface. 

[15]  ANS  Tl  .604-1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Minimal 
Set  of  Bearer  Services  for  the  Basic  Rate  Interface. 

[16]  ANS  Tl. 605-1989,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Basic 
Access  Interface  at  S  and  T  Reference  Points  —  Layer  1  Specification. 


NIU-Forum  Agreements  On  ISDN 


8-1 


[  1 7]  ANS  Tl  .607- 1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Digital 
Subscriber  Signalling  System  Number  I  (DSSI)  —  Layer  3  Signalling  Specification  for  Circuit- 
Switched  Bearer  Service. 

[  1 8]  ANS  Tl  .608- 1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Digital 
Subscriber  Signalling  System  Number  I  (DSSI)  —  Signalling  Specification  for  X.25  Packet- 
Switched  Bearer  Service. 

[19]  ANS  Tl.609-1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  — 
Interworking  between  the  ISDN  User-Network  Interface  Protocol  and  the  Signalling  System 
Number  7  (SS7)  ISDN  User  Part. 

[20]  ANS  Tl.610-1990,  Telecommunications  —  Integrated  Services  Digital  Network  (ISDN)  —  Digital 
Subscriber  Signalling  System  Number  I  (DSSI)  —  Generic  Procedures  for  the  Control  of  ISDN 
Supplementary  Services. 

[21]  ANS  Tl. 612-1990,  Telecommunications — Integrated  Services  Digital  Network  (ISDN)  —  Terminal 
Adaptation  Using  Statistical  Multiplexing. 

[22]  TlSl.2/92-185  (TIS  1.2/90-030),  Supplementary  Service  —  Normal  Call  Transfer  Stage  1,  2  and 
3. 

[23]  TlSl/92-629  (TBATl.626-1992),  Draft  Proposed  American  National  Standard- Switch-Computer 
Applications  Interface  (SCAI). 

8.2        CCITT  Documents 

[24]  CCITT  Recommendation  1.431-1988,  ISDN  Primary  Rate  User-Network  Interface  —  Layer  1 
Specification. 

[25]  CCITT  Recommendation  Q.921-1988  (also  designated  CCITT  Recommendation  1.441-1988),  ISDN 
User-Network  Data  Link  Layer  Specification. 

[26]  CCITT  Reconmiendation  Q.93 1-1988  (also  designated  CCITT  Recommendation  1.45 1-1988),  ISDN 
Primary  Rate  User-Network  Interface  —  Layer  3  Specification. 

[27]  CCITT  Recommendation  V.120-1988,  Support  by  an  ISDN  of  Data  Terminal  Equipment  with  V- 
series  Type  Interfaces  with  Provision  for  Statistical  Multiplexing. 

[28]  CCITT  Recommendation  X.25-1984,  Interface  between  Data  Terminal  Equipment  (DTE)  and  Data 
Circuit-Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  and  Connected 
to  Public  Data  Networks  by  Dedicated  Circuit. 

[29]      CCITT  Recommendation  X.31-1988,  Support  of  Packet  Mode  Terminal  Equipment  by  an  ISDN. 

[30]      CCITT  Recommendation  1.231-1988,  Circuit-Mode  Bearer  Service  Categories. 

[31]      CCITT  Recommendation  1.232-1988,  Packet-Mode  Bearer  Services  Categories. 


NIU-Forum  Agreements  on  ISDN 


21 


8.3        NIU-Forum  Documents 

[32]  NIU  Publication  1,  North  American  ISDN  Users'  Forum  (NIU-Forum)  Working  Agreements  for 
the  Integrated  Services  Digital  Network  (ISDN),  01  June  1990. 

[33]  NIU  90-002  (NIU/IIW/ICOT/90-40),  Integrated  Services  Digital  Network  (ISDN)  Conformance 
Testing,  Layer  1  Basic  Rate  S/T  Interface,  User  Side,  1990. 

[34]  NIU  91-007  (NIU/IIW/ICOT/ACT23/9 1-22.2  V1.2),  Integrated  Services  Digital  Network  (ISDN) 
Conformance  Testing,  Layer  2  Basic  Rate  Interface,  Link  Access  Procedure,  D-channel  (LAPD), 
User  side,  1991. 

[35]  NIU-Forum  User  Application  Requirements  Data  Form  810004,  "Data  Conferencing  (Point  to 
Point)." 

[36]  NIU-Forum  User  Application  Requirements  Data  Form  810005,  "Database  Information  to 
Corporate  Security." 

[37]  NIU-Forum  User  Application  Requirements  Data  Form  840023,  "New  Account  Customer  Inquiry 
Handling." 

[38]  NIU-Forum  User  Application  Requirements  Data  Form  840024,  "Customer  Service  Call  Handling 
(Incoming  Call  Management)." 

[39]      NIU-Forum  User  Application  Requirements  Data  Form  840025,  "Automatic  Callback  for 
Financial  Services." 

[40]      NIU-Forum  User  Application  Requirements  Data  Form  830008,  "Asynchronous  to 
SNA/SDLC." 

[41]      NIU-Forum  User  Application  Requirements  Data  Form  830(X)9,  "Synchronous  Terminal  to 
Controller." 

[42]      NIU-Forum  User  Application  Requirements  Data  Form  960009,  "Asynchronous  Access  to  Host 
Computer." 

[43]      NIU-Forum  User  Application  Requirements  Data  Form  83(X)13,  "Building  Controls." 

[44]      NIU-Forum  User  Apphcation  Requirements  Data  Form  860016,  "Transparent  Networking  of 
Voice  Messaging  Systems." 

[45]      NIU-Forum  User  Application  Requirements  Data  Form  860018,  "Interface  to  Voice  Messaging 
Systems." 

[46]      NIU-Forum  User  Application  Requirements  Data  Form  810034,  "Interface  to  Centralized  Voice 
Messaging  System." 


^'These  documents  are  available  by  contacting  the  NIU-Forum  Administrator,  NIST,  Building  223, 
Room  B364,  Gaithersburg,  MD  20899. 


NIU-Forum  Agreements  On  ISDN 


8-3 


[47]       NIU-Forum  User  Application  Requirements  Data  Form  050015,  "Secure  Voice  Mail." 

[48]      NIU-Forum  User  Application  Requirements  Data  Form  050014,  "Secure  E-Mail." 

[49]      NIU-Forum  User  Application  Requirements  Data  Form  050016,  "Secure  Facsimile 
Transmission  through  ISDN." 

[50]      NIU-Forum  User  Applicadon  Requirements  Data  Form  960029,  "ISDN  Station  Event 
Recording  (ISER)." 

8.4        Other  Documents 

[51]      NIST  Special  Publication  500-195,  North  American  ISDN  Users'  Forum  Agreements  on 
Integrated  Services  Digital  Network,  September  1991. 

[52]      NIST  Special  Publication  500-183,  Stable  Implementation  Agreements  for  Open  Systems 
Interconnection  Protocols,  Version  5,  Edition  1,  December  1991. 

[53]      NIST  Special  Publication,  Application  Software  Interface  Part  1:  Overview  and  Protocols, 
September  1991. 

[54]      ISO  9646,  Information  Processing  Systems,  OSI  Conformance  Testing  Methodology  and 
Framework.  Parts  1-5,  1989. 


8-4 


NIU-Forum  Agreements  on  ISDN 


APPENDIX  A. 


NIU  90-301 
Implementation  Agreement 
of  the  North  American  ISDN  Users'  Forum 

Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for 
the  ISDN  Basic  Rate  Interface/Class  I. 

Baseline  Text 

American  National  Standard  Tl.607-1990: 
Integrated  Services  Digital  Network  (ISDN)  — 
Layer  3  Signalling  Specification  for 
Circuit-Switched  Bearer  Service  for 
Digital  Subscriber  Signalling  System  Number  1  (DSSl). 

Base  Standards 
CCITT  Recommendation  Q.931  (1988): 
ISDN  User-Network  Interface  Layer  3  — 
Specification  For  Basic  Call  Control. 

ANSI  Tl.607-1990 
ANSI  T1.604*: 

Integrated  Services  Digital  Network  (ISDN)  — 
Minimal  Set  of  Bearer  Services  for 
the  Basic  Rate  Interface. 


A.l  Abstract 

This  Implementation  Agreement  specifies  procedures  for  establishing,  maintaining,  and  clearing  connections  at  the 
Integrated  Services  Digital  Network  (ISDN)  user-network  interfaces  and  are  mandatory  for  the  support  of  the  minimal 
set  of  circuit-switched  bearer  services  specified  by  ANSI  Tl  .604-1990'  Integrated  Services  Digital  Network  (ISDN) 

—  Minimal  Set  of  Bearer  Services  for  the  Basic  Rate  Interface,  (Ref  [15]).  Procedures  for  circuit-mode  digital, 
circuit-mode  speech  and  circuit-mode  voiceband  data  bearer  services  are  as  specified  in  the  baseline  text  ANS 
Tl  .607-1990,  Integrated  Services  Digital  Network  (ISDN)  —  Digital  Subscriber  Signalling  System  Number  1  (DSSl) 

—  Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref  [17])  as  further  resolved  by  this 
agreement.  The  packet-mode  data  service  is  included  in  this  document  as  a  bearer  service.  Procedures  for  the 
packet-mode  bearer  service  will  be  detailed  in  another  document. 
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A.2  Introduction 


The  original  implementation  agreement  (NIU  90-301)  was  reached  by  marking  up  the  text  of  ANS  Tl. 607-1990, 
(Ref.  [17])  to  reflect  the  clarifications  of  text  and  selection  of  options.  This  appendix  translates  the  implementation 
agreement  markup  into  a  listing  of  these  clarifications  and  selections,  (i.e.,  this  appendix  lists  the  differences  (the 
"delta")  between  the  implementation  agreement  marked  up  ANS  Tl.607-1990,  and  the  original  text  of  ANS  T1.607- 
1990). 

A.3  NIU  90-301  Delta  List" 

The  lA  has  adopted  the  ANS  Tl.607-1990'"  (Ref.  [17])  standard  with  the  following  clarifications  of  the  text,  and 
selection  of  options: 


ANS  Tl.607-1990 
SECTION/TABLE  NUMBER/NAME 


Section  1 
General 

Section  1.1 
Scope  and  Purpose 

Section  2.2 

States  associated  with  the  global  reference 
call 

Section  3 

Message  functional  definition  and  content 
Item  (b),  Subitem  (2) 

Section  3.1 

Messages  for  circuit-mode  connection  control 
Table  1  —  Messages  for  circuit-mode  connection 
control 

Section  3.1 

Messages  for  circuit-mode  connection  control 
Table  1  —  Messages  for  circuit-mode  connection 
control 


IMPLEMENTATION  AGREEMENTS  - 
CLARIFICATION  OF  TEXT  AND 
SELECTION  OF  OPTIONS 

Delete  "1.  General"  heading. 

Replace  this  section  with  Attachment  A  of  this 
document. 

Delete  this  section  including  subsections. 


Delete  last  sentence  from  the  Note:  "Annex  D 
contains  a  description  of  the  information  element 
usage  for  symmetric  NT2-NT2  interfaces." 

Change  "NOTIFY  3.1.7"  to  "*NOTIFY". 


Add  the  following  footnote  below  table  1:  "*  See 
section  5.8.4  for  treatment  of  this  message." 


"Note  that  this  Delta  List  was  developed  in  "good  faith"  by  NIST  as  a  simple  equivalent  representation  of  the 
actual  agreements.  It  has  been  reviewed  and  approved  by  the  editors  of  the  Signalling  Working  Group  as  per 
recommendation  of  the  Executive  Steering  Committee. 

"'This  documents  can  be  purchased  from:  American  National  Standards  Institute,  1 1  West  42nd  Street,  New 
York,  NY  10036. 

^.2  NIU-Forum  Agreements  on  ISDN 


Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Channel  Identification/Direction"  cell 
from  "both  (Note  1)"  to  "u  ->  n". 


Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Change  the  "Progress  Indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,4". 


Delete  "Display"  row. 


Delete  Notes  1,  4,  5. 


Delete  the  last  sentence  from  Note  3. 


Change  Note  "6  Included  if  the  network  optionally 
provides  additional  information  describing  tones."  to 
"6  The  network  will  always  provide  this  IE." 

Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Delete  reference  to  "Note  2"  in  the  "Progress 
indicator/Type"  cell. 

Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,  4". 


Delete  "Display"  row. 
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Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 
Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 


Delete  Notes  2,  3,  4. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Channel  Identification/Direction"  cell 
from  "both  (Note  1)"  to  "u  ->  n  (Note  1)". 


Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "3". 


Change  the  "Progress  indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from  "2- 
4"  to  "2.  4". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Low  Layer  compatibility". 

Change  Note  1  from  "Included  in  the  network-to-user 
direction  for  support  of  the  procedures  in  Annex  D." 
to  "The  coding  of  this  IE  should  be  always  'Exclusive 
B'." 

Delete  the  following  from  Note  3:  "or  in  connection 
with  the  provision  of  in-band  tones  and  patterns." 

Delete  Notes  4,  5,  7,  8.  9. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 
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Section  3.1.4  Delete  "Display"  row. 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 


Section  3.L4  Delete  Notes  \,  2. 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 


Section  3.L4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.L5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 


Change  Note  3  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
Alerting  off." 

Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  Number"; 

•  "Connected  subaddress". 


Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 


Delete  Notes  1,  2,  4,  5. 

Change  Note  3  to:  "Included  if  the  network  must 
turn  tones  on  or  off,  or  turn  ALERTING  off." 

Change  the  "Call  Reference/Length"  cell  from 
"2-*"  to  "2-3". 

Delete  "Display"  row. 

Change  the  "Keypad  Facility/Length"  cell  from 
"2-34"  to  "3-34". 

Delete  Notes  2,  3. 
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Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 

Section  3.1.6 
INFORMATION 

Table  7  —  INFORMATION  message  content 


Add  the  following  to  the  end  of  Note  4  ("The  Keypad 
facility  information  element..."):  "When  INFO  is  sent 
u  ->  n,  this  IE  must  be  present." 

Change  Note  5  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
tones  off." 


Section  3.1.7 
NOTIFY 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 


Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Delete  this  section. 


Change  "Direction"  in  table  header  from  "both"  to 
"n  ->  u". 


Change  the  "Direction"  cell  in  the  following  rows 
from  "both"  to  "n  ->  u": 

•  "Protocol  discriminator"; 

•  "Call  reference"; 

•  "Message  type"; 

•  "Cause"; 

•  "Progress  Indicator". 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from 
"2-32"  to  "2,4-10". 


Delete  "Display"  row. 


Delete  Notes  2,  3. 


Change  Note  4  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  when  tones  or  some 
announcement  are  provided  in-band." 

Change  the  "Call  reference/Length"  cell  from  "2-*" 
to  "2-3". 
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Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  11  —  RELEASE  COMPLETE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2,4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  6,  7. 


Change  Note  5  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the.  network  must  turn  tones  or 
Alerting  off." 

Change  the  "Call  reference/LengUi"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Lengtii"  cell  from  "2-32"  to  "2,  4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Connected  number" 

•  "Connected  subaddress". 


Section  3.1.10  Delete  Notes  3,  4,  6,  7. 

RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Change  Note  5  from  "Included  if  Uie  network 
optionally  provides  additional  information  describing 
tones."  to  "Included  if  the  network  is  required  to  turn 
tones  on  or  off." 

Change  Uie  "Call  Reference/Length"  cell  from 
"2-*"  to  "2-3". 


Delete  the  following  rows: 

•  "Repeat  Indicator"; 

•  "Network-Specific  Facilities"; 

•  "Display". 
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Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 
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Delete  from  the  "Bearer  Capability/Type"  cell  the 
reference  to  Note  2. 


Change  the  "Bearer  Capability/Length"  cell  from 
"4-13"  to  "4-8". 


Change  the  "Channel  Identification/Length"  cell  from 
"2-*"  to  "2-3". 


Change  the  "Progress  Indicator/Direction"  cell  from 
"both"  to  "n  ->  u". 


Change  the  "Progress  Indicator/Length"  cell  from 
"2-4"  to  "2,4". 


Change  the  "Calling  party  number/Length"  cell  from 
"2-*"  to  "2-19". 


Change  the  "Called  party  address/Length"  cell  from 
"2-*"  to  "2-18". 


Change  the  "Transit  Network  Selection/Length"  cell 
from  "2-*"  to  "2-7". 


Change  the  "Higher  Layer  Compatibility/Length"  cell 
from  "2-4"  to  "2-5". 


Delete  Notes  1,  2,  5,  6,  7. 


Add  to  the  end  of  Note  8:  "The  digits  in  this  IE  are 
0  to  9,  *,  and  #." 

Change  Note  9  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones."  to  "The  network  will  always  provide  this  IE." 

Add  to  the  end  of  Note  13:  "The  network  should 
transport  this  IE  transparently.  This  IE  is  optional  on 
the  user  side." 

NIU-Forum  Agreements  on  ISDN 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 

Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Add  to  the  end  of  Note  15:  "The  network  should 
transport  this  IE  transparently.  This  IE  is  optional  on 
the  user  side.  The  total  length  is  2  to  16  octets." 

Add  to  the  end  of  Note  16:  "The  network  should 
transport  this  IE  transparently.  This  IE  is  optional  on 
the  user  side." 

Add  to  the  end  of  Note  17:  "The  network  will  treat 
this  IE  on  sending  and  receiving  as  described  in  the 
User-User  supplementary  service  Implementation 
Agreement." 

Delete  "and  7kHz  audio"  from  Note  20. 


Change  the  "Call  Reference/Length"  cell  from  "2-*" 
to  "2-3". 


Change  the  "Channel  Identification/Type"  cell  from 
"M"  to  "M*". 


Add  the  following  footnote  before  Note  1:  "*  The 
coding  of  the  channel  ID  should  always  be  'Exclusive 
B'." 


Change  the  "Channel  Identification/Length"  cell 
from  "3-*"  to  "3". 


Change  the  "Progress  Indicator/Length"  cell  from  "2- 
4"  to  "2,4". 


Delete  "Display"  row. 


Change  Note  1  to:  "The  only  valid  value  for  progress 
indicator  is  8  (refer  to  section  4.5.21  octet  4). 
Included  in  connection  with  the  provision  of  in-band 
information/patterns." 
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Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Delete  Notes  2,  3. 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Table  13  —  SETUP  ACKNOWLEDGE  message 
content 


Cliange  Note  4  from  "Included  if  the  network 
optionally  provides  additional  information  describing 
tones  (e.g.,  activate  dial  tone)."  to  "Included  if  the 
network  is  required  to  turn  on  dial  tone." 


Section  3.1.13 
STATUS 


Change  the  first  sentence  from  "This  message  is  sent 
by  the  user  or  the  network  in  response  to  a  STATUS 
ENQUIRY  message  or  at  any  time  during  a  call  to 
report  certain  error  conditions  as  listed  in  5.8."  to 
"This  message  is  sent  by  the  user  in  response  to  a 
STATUS  ENQUIRY  message  sent  by  the  network,  or 
by  either  the  user  or  the  network  to  report  certain 
error  conditions  as  Hsted  in  5.8." 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Call  Reference/Length"  cell  "2-*"  to  "2- 
3". 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Delete  "Display"  row. 


Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Delete  Notes  1,  2. 


Section  3.1.14 
STATUS  ENQUIRY 


Change  "This  message  is  sent  by  the  user  or  the 
network  at  any  time  to  solicit  a  STATUS  message 
from  the  peer  layer  3  entity."  to  "This  message  is  sent 
by  the  network  during  the  active  state  to  solicit  a 
STATUS  message  from  the  peer  layer  3  entity." 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 


Change  "Direction"  in  the  table  header  from  "both"  to 
"n  ->  u". 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 


Change  the  "Direction"  cell  in  the  following  rows 
from  "both"  to  "n  ->  u": 

•  "Protocol  discriminator"; 

•  "Call  reference"; 

•  "Message  type". 
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Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 
Section  3.2 

Messages  used  with  the  global  call  reference 
Section  4.2 

Protocol  Discriminator 


Section  4.2 

Protocol  Discriminator 

Figure  2  —  Protocol  Discriminator 

Section  4.2 

Protocol  Discriminator 

Table  19  —  Protocol  Discriminator 

Section  4.3 
Call  Reference 


Section  4.3 
Call  Reference 

Section  4.3 
Call  Reference 


Section  4.3 
Call  Reference 

Section  4.3 
Call  Reference 

Section  4.4 

Message  Type 

Table  20  —  Message  types 


Change  "Call  Reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  "Display"  row. 


Delete  Notes  1,  2. 


Delete  this  section  including  subsections. 

Add  the  following  paragraph  after  the  second 
paragraph.  "The  only  value  supported  for  call  control 
messages  is  described  below,  in  Figure  2." 

Change  "ANSI  T1.607"  to  "Q.931". 


Change  "ANSI  T1.607"  to  "Q.931"  in  the  row  labeled 
"0000  1000". 


Change  the  first  sentence  of  the  third  paragraph  from 
"...  for  a  basic  user-network  interface,  and  a  call 
reference  value  of  two  octets  for  a  primary  rate 
interface."  to  "and  a  maximum  of  2.  The  network 
will  send  one  octet  call  reference  value  (CRV)  unless 
all  127  available  codepoints  are  occupied." 

Delete  the  fourth  paragraph  "As  a  network  option  ... 
one  or  two  octets." 

Add  "The  Dummy  Call  Reference  and  the  Global  Call 
Reference  are  not  supported  for  BRl/Class  1  circuit- 
switched  calls."  after  figure  5. 

Delete  the  last  sentence  from  the  eighth  paragraph 
"The  call  reference  ...  (e.g..  Restart  procedures)." 

Delete  Note  2  ("The  numerical  value  ...  defined  in 
3.2."). 

Add  an  asterisk  (*)  to  the  beginning  of  the  "NOTIFY" 
row. 
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Section  4.4 

Message  Type 

Table  20  —  Message  Types 

Section  4.5.1 
Coding  Rules 

Section  4.5.1 
Coding  Rules 

Figure  7  —  Formats  of  information  elements 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Add  as  a  footnote  "*  See  section  5.8.4  for  treatment 
of  this  message  type." 

Delete  the  last  3  sentences  of  the  fourth  paragraph 
"Two  types  of  ...  octet  elements." 

Delete  Figure  7  (b).  Single  octet  information  element 
format  (type  2). 


Delete  "Repeat  Indicator"  row. 


Delete  reference  to  Note  6  in  row  "Bearer  capability". 


Change  the  "Bearer  capability/max  length"  cell  from 
"13"  to  "8". 


Change  the  "Cause/max  length"  cell  from  "32"  to 
"10". 


Change  the  "Cause/max.  no.  of  occurrences"  cell  from 
"3"  to  "2". 


Change  the  "Channel  identification/max  length"  cell 
from  "(Note  4)"  to  "3". 


Delete  the  following  rows: 

•  "Network-specific  facilities"; 

•  "Notification  indicator"; 

•  "Display"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Change  Uie  "Calling  Party  Number/max  length"  cell 
from  "(Note  4)"  to  "19". 


Change  die  "Called  Party  Number/max  length"  cell 
"(Note  4)"  to  "18". 
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Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Delete  reference  to  Note  2  in  the  "Transit  Network 
selection"  row. 


Change  the  "Transit  Network  selection/max  length" 
cell  from  "(Note  4)"  to  "7". 


Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Delete  "4"  from  the  "Transit  Network  Selection/max. 
no.  of  occurrences"  cell. 


Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 


Delete  the  following  rows: 

•  "Restart  indicator"  and 

•  "Escape  for  extension". 


Section  4.5.1 
Coding  Rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  Rules 

Figure  8  —  Information  element  format  using  escape 
for  extension 


Delete  Notes  3,  4,  and  6. 


Delete  this  figure. 


Section  4.5.2 
Extensions  of  codesets 


Change  "T1.608"  to  "NIU  89-320"  in  the  first  bullet 
in  the  fourth  paragraph. 


Section  4.5.2 
Extensions  of  codesets 


Change  the  ninth  paragraph  to:  "Codeset  7 
information  elements  shall  be  handled  according  to 
the  procedures  for  unrecognized  information  elements 
(see  5.8.7.1)  by  the  first  exchange." 


Section  4.5.2 
Extensions  of  codesets 


Delete  the  tenth  paragraph  ("Codeset  6  ...  bilateral 
agreements."). 


Section  4.5.3 

Locking  shift  procedure 

New  codeset  identification  coding 

Section  4.5.4 

Non-locking  shift  procedures 
Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  coding 

Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  coding 


Change  "T1.608"  to  "NIU  89-320"  in  row  "codeset 
5". 


Delete  "(a)  process  the  non-locking  ...  below."  from 
the  second  paragraph. 

Change  "T1.607"  to  "NIU  90-301"  in  row  "codeset 
0". 

z 

Change  "T1.608"  to  "NIU  89-320"  in  row  "codeset 
5". 
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Section  4.5.5 
Bearer  capability 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 


Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  capability 


Section  4.5.5 
Bearer  capability 

Information  transfer  capability  (octet  3)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octet  4)  coding 

Section  4.5.5 
Bearer  capability 

Information  transfer  rate  (octet  4)  coding 


In  the  second  paragraph  change  "13  octets"  to  "8 
octets". 

Change  octet  4,  bit  8  from  "0/1"  to  "1". 


Delete  octets 

•  4a*; 

•  4b*; 

•  5b*  Note  2; 

•  5b*  Note  3; 

•  5c*; 

•  5d*. 

Change  octet  5a*,  bit  8  from  "0/1"  to  "1". 


Delete  Notes  1,  2,  and  3. 


Delete  "or  V.120"  from  the  end  of  Note  4. 


Add  the  following  after  Figure  11:  "Octets  6  and  7 
are  included  for  information  only  and  shall  not  be 
used  for  circuit-switched  calls.  The  coding  and 
application  for  these  octets  are  included  in  another 
document." 

Delete  row  "10001  7  kHz  audio". 


Change  the  title  to  "Information  transfer  rale  (octet 
4)". 


Delete  the  following  rows: 

•  "10011  384  kbit/s"; 

•  "10100  1472  kbit/s  (see  Note  2)"; 

•  "10101  1536  kbit/s". 

Change  Note  1  to:  "The  bearer  capability  is 
bidirectional  symmetric  at  the  information  transfer 
rate  specified  in  octet  4." 
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Information  transfer  rale  (octet  4)  coding 

Section  4.5.5 
Bearer  capability 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 
Negotiation  (octet  5a)  coding 

Section  4.5.5 

Bearer  capability 

User  rate  (octet  5a)  coding 

Section  4.5.5 
Bearer  capability 


Section  4.5.5 
Bearer  capability 

Section  4.5.6 
Call  state 

Global  interface  state  value  (octet  3)  coding 


Delete  Note  2. 


Delete  the  codings  of  octets  4a  (structure, 
configuration,  establishment)  and  4b  (symmetry). 

Delete  "and  optionally  octets  5b,  5c,  and  5d  as 
defined  below."  from  row  "00001". 


Delete  "and  G.725  7  kHz  audio"  from  row  "00101". 


Delete  rows  "00111"  and  "01000". 


Delete  Note  2. 


Delete  row  "1  asynchronous". 


Delete  the  second  and  third  sentences  from  the  Note. 


Delete  row  "1  In-band  negotiation  possible". 


Delete  all  code  points  except  "01111  56  kbit/s 
CCITT  Recommendation  V.6." 


Delete  all  text  relating  to  octet  5b  (i.e.,  sections 
labeled  "Octet  5b  for  CCITT  Recommendation  V.lOO 
or  X.30  rate  adaption"  and  "Octet  5b  for  CCITT 
Reconmiendation  V.120  rate  adaption"). 

Delete  all  tables  and  text  referring  to  octets  5c 
(number  of  data  bits  excluding  parity  bit,  parity 
information)  and  5d  (duplex  mode,  modem  type). 

Delete  this  coding. 
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Section  4.5.7 
Called  party  number 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Section  4.5.7 
Called  party  number 

Numbering  plan  identification  (octet  3)  coding 


Section  4.5.7 
Called  party  number 


Section  4.5.9 
Calling  party  number 


Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 

Numbering  plan  identification  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  18  octets." 

Delete  the  following  rows: 

•  "Oil  network  specific  number  (see  Note  4)"  and 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

"0011     Data    numbering     plan  (CCFFT 
Recommendation  X.121)"; 

"0100       Telex    numbering    plan  (CCFFT 
Recommendation  F.69)"; 

•  "1111  Reserved  for  extension". 

Add  Attachment  B  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering  and  dialing  plan." 

Change  the  second  paragraph  from:  "The  maximum 
length  of  this  information  element  is  network 
dependent."  to  "The  maximum  length  of  this 
information  element  is  19  octets." 

Delete  the  following  rows: 

•  "Oil  network  specific  number  (see  Note  4)"  and 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

"0100       Telex    numbering    plan  (CCFFT 
Recommendation  F.69)"  and 
•  "1111  Reserved  for  extension". 

Add  Attachment  C  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering  or  dialing  plan." 
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Section  4.5.10 

Calling  party  subaddress 


Section  4.5.11 
Cause 


Add  a  new  paragraph  at  the  end  of  the  section:  "In 
the  network  to  user  direction  (n  — >  u),  the  coding 
and  delivery  of  this  IE  depends  on  the  definition  of 
the  Calling  Line  ID  service." 

Change  the  second  sentence  of  the  first  paragraph 
from  "The  maximum  length  of  this  information 
element  is  32  octets."  to  "The  maximum  length  of  this 
information  element  is  10  octets." 


Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Reconmiendation  (octet  3a)  coding 

Section  4.5.11 
Cause 


Section  4.5.11 
Cause 
Cause  table 


Change  octet  3,  bit  8  from  "0/1"  to  "1". 


Delete  octet  3a*. 


Delete  the  Note. 


Delete  this  coding  and  its  associated  Notes  1  and  2. 


Add  the  following  sentence  to  the  end  of  the 
paragraph  under  "Diagnostics  (octet  5)":  "If  more 
than  one  IE  is  identified  in  a  diagnostic,  they  should 
be  ordered  as  lE's  normally  appear  in  a  message." 

Change  the  "diagnostics"  cell  of  the  first  three  code 
points  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "Normal  call  clearing/diagnostics"  cell 
from  "(see  Note  12)"  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Add  to  the  "User  busy/diagnostics"  cell:  "(see  Note 
10)" 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "call  rejected/diagnostics"  cell  from  "(see 
Note  12,  user  supplied  diagnostic)  (see  Note  4)"  to 
"Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Delete  row  "Number  changed". 
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Section  4.5.11 
Cause 
Cause  table 


Add  "(see  Note  10)"  to  the  "Network  out  of 
order/diagnostics"  cell. 


Section  4.5.11 
Cause 
Cause  table 


Add  "(see  Note  10)"  to  the  "Requested  circuit  or 
channel  not  available/diagnostics"  cell. 


Section  4.5.11 
Cause 
Cause  table 


Delete  row  "Quality  of  service  unavailable". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "Requested  facility  not  subscribed/ 
diagnostics"  cell  from  "Facility  identification  (see 
Note  D"  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "Bearer  capability  not  authorized/ 
diagnostics"  cell  from  "(see  Note  3)"  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Delete  row  "Bearer  capability  not  presently  available". 


Section  4.5.11 
Cause 
Cause  table 


Delete  row  "Service  or  option  not  available, 
unspecified". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "Bearer  capability  not  implemented/ 
diagnostics"  cell  from  "(see  Note  3)"  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Delete  row  "Channel  type  not  implemented". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "requested  facility  no  implemented/ 
diagnostics"  cell  from  "Facility  identification  (see 
Note  1)"  to  "Not  used". 


Section  4.5.11 
Cause 
Cause  table 


Delete  rows  "Only  restricted  digital  information 
bearer  capability  is  available"  and  "Service  or  option 
not  implemented,  unspecified". 


SecUon  4.5.11 
Cause 
Cause  table 


Delete  row  "Identified  channel  does  not  exist". 


Section  4.5.11 
Cause 
Cause  table 


Change  the  "incompatible  destination/diagnostics"  cell 
from  "Incompatible  parameter  (see  Note  2)"  to  "Not 
used". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 

Figure  18  —  Coding  of  the  diagnostic  field  for  causes 
57,  58  and  65 

Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 

Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 

Section  4.5.12 

Channel  identification 

Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 

Channel  identification 

Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 

Section  4.5.12 
Channel  identification 


Delete  row  "Invalid  message,  unspecified". 

Change  the  "Recovery  on  timer  expiry/diagnostics" 
cell  from  "Timer  number  (see  Note  9)"  to  "Not  used". 

Delete  Notes  2,  3,  4,  5,  7,  9,  11,  12. 

Delete  Figure  18  and  text  for  octets  5,  5a,  and  5b. 

Delete  the  octets  3.1,  3.2,  and  3.3. 


Delete  Notes  1,  2,  3,  4. 


Delete  row  "1  Interface  explicitly  ...  with  octet  3.1." 


Delete  the  Note  and  the  reference  to  it  in  row  "0 
Interface  implicitly  identified". 

Delete  row  "1  other  interface:  ...  (see  Note)". 


Delete  the  Note. 


Add  the  following  after  Note  3:  "4  The  combination 
of  'Any  Channel'  (bits  1,2),  and  'Exclusive'  (bit  4)  is 
invalid." 

Delete  the  text,  codings,  and  figures  relating  to  octets 
3.1,  3.2,  and  3.3. 
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Section  4.5.13 
Connected  Number 


Delete  this  section. 


Section  4.5.14 
Connected  subaddress 

Section  4.5.15 
Display 

Section  4.5.16 

High  layer  compatibility 


Section  4.5.18 

Low  layer  compatibility 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

SecUon  4.5.18 

Low  Layer  compatibility 

User  information  layer  3  protocol  (octet  7)  coding 

Section  4.5.19 
Network-specific  facilities 

Section  4.5.20 
Notification  Indicator 

Section  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.22 
Repeat  indicator 

Section  4.5.23 
Restart  indicator 


Delete  this  section. 


Delete  this  section. 


Change  the  second  paragraph  from  "The  maximum 
length  of  this  information  element  is  four  octets."  to 
"The  maximum  length  of  this  information  element  is 
five  octets." 

Delete  the  second  paragraph. 

Delete  row  "1  Out-band  negotiation  possible". 


Delete  Note  1. 


Change  "ANSI  T1.607"  to  "NIU  90-301"  in  row 
"00010". 


Delete  this  section. 


Delete  this  section. 


Delete  row  "000  0100  4  call  has  returned  to  the 
ISDN." 


Add  the  following  after  Note  2:  "3  In  the  SETUP 
message,  n  ->  u,  one  of  two  values  may  be  used:  1  or 
3." 

Delete  this  section. 


Delete  this  section. 
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Section  4.5.24 
Signal 

Figure  32  —  Signal  information  element 

Section  4.5.24 
Signal 

Signal  value  (octet  3)  coding 


Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 

Type  of  network  identification  (octet  3)  coding 

Section  4.5.25 

Transit  network  selection 

Network  identification  plan  (octet  3)  coding 

Section  4.5.26 
User-user 


Section  4.5.26 
User-user 

Protocol  discriminator  (octet  3)  coding 

Section  4.6.1 

Operator  system  access 

type  of  access  (octet  3)  coding 

Section  5 

Circuit-switched  call  control  procedures 
Section  5 

Circuit-switched  call  control  procedures 
Section  5.1 

Call  establishment  at  the  originating  interface 


Add  below  the  figure:  "Note  In  the  n  ->  u  direction, 
and  in  the  absence  of  supplementary  services,  the 
public  network  will  offer  signalling  pattern  0  only." 

Delete  the  following  rows: 

•  "intercept  tone  on"; 

•  "answer  tone  on"; 

•  "off  hook  warning  tone  on"; 

•  "ALERTING  on  —  pattern  5"; 

•  "ALERTING  on  —  pattern  6"; 

•  "ALERTING  on  —  pattern  7". 

Change  the  second  sentence  of  the  fu-st  paragraph  to: 
"The  transit  network  selection  information  element 
should  not  be  repeated  in  a  message  (See  Annex  C)." 

Change  the  second  paragraph  to:  "The  default 
maximum  length  of  tliis  information  element  is  7 
octets." 

Delete  row  "Oil  international  network  identification". 


Delete  row  "(X)ll  Data  network  identification  code 
(CCITT  Recommendation  X.121)". 


Add  the  following  sentence  to  the  end  of  the  Note 
(after  the  second  paragraph):  "This  IE  is  included 
based  on  user-user  supplementary  service  description 
and  user  application." 

Change  "ANSI  T1.607"  to  "NIU  90-301"  in  row 
"0000  1000". 


Delete  row  "10  private/principal". 


Delete  the  fourth  paragraph  ("As  a  general  principle, 
..."). 

Delete  the  last  sentence  of  second  Note  ("Display 
information  ...  network  to  user."). 

Change  "ANSI  T1.602"  to  "NIU  89-210"  in  the  last 
sentence  of  the  first  paragraph. 
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Section  5.1.3 
Overlap  sending 


Section  5.1.4 

Invalid  call  information 

Section  5.1.4 

Invalid  call  information 


Add  the  following  at  the  end  of  section  5.1.3: 
"However,  as  an  option,  the  network  can  determine 
that  a  potentially  complete  code  has  been  received 
following  the  receipt  of  address  information,  and  the 
network  could  use  critical  interdigit  timing  (instead  of 
T302)  to  determine  whether  additional  digits  are 
following.  This  timing  could  be  3-5  seconds.  If 
implemented,  when  this  timer  expires,  a  complete 
address  is  assumed  and  the  procedures  in  Sec.  5.1.5.2 
shaU  be  followed.  In  an  INFORMATION  message  is 
received  and  the  critical  interdigit  timing  is  running, 
it  shall  be  stopped." 

Delete  the  following  line  from  the  last  paragraph: 
"22  'number  changed'." 

Add  the  following  two  paragraphs  to  the  end  of 
section  5.1.4: 

"The  network  should  reject  the  call  request  if  the 
SETUP  message  contains  the  keypad  information 
element,  and  any  of  the  following  information 
elements:  transit  network  selection,  called  party 
number,  or  operator  system  access.  In  this  case,  the 
network  should  send  the  calling  user  equipment  a 
RELEASE  COMPLETE  message  containing  cause  28, 
'invaUd  number  format  (location:  public  network 
serving  the  local  user).'." 

"If  the  network  receives  a  called  party  number 
information  element  containing  more  address  digits 
than  expected,  as  determined  by  the  'type  of  number 
and  numbering  plan  identification'  field,  the  network 
should  discard  the  superfluous  digits  and  route  the 
call.  Similarly,  if  the  transit  network  selection 
information  element  contains  more  address  digits  than 
expected,  as  determined  by  the  'type  of  network 
identification'  and  'network  identification  plan'  fields, 
the  network  should  discard  the  superfluous  digits  and 
route  the  call.  If  the  network  receives  a  keypad 
information  element  containing  more  address  digits 
than  required  for  completion  of  digit  analysis,  the 
network  should  discard  the  superfluous  digits 
(according  to  the  network  dialing  plan)  and  route  the 
call.  If  any  of  these  events  occur,  the  local  pubUc 
network  should  send  the  calling  user  equipment  a 
STATUS  message  containing  National-specific  cause 
11,  'More  digits  received  than  allowed:  call  is 
proceeding  (location:  pubhc  network  serving  the  local 
user'  and  the  call  state  information  element  coded  as 
call  state  1,  'call  initiated.'  Private  networks  may 
support  this  procedure,  optionally." 
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Section  5.1.5.1 

Call  proceeding,  en-bloc  sending 


Delete  causes  "58  'bearer  capability  not  presently 
available';"  and  "63  'service  or  option  not  available, 
unspecified';"  from  the  second  paragraph. 


Section  5.1.5.1 

Call  proceeding,  en-block  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.5.2 

Call  proceeding,  overlap  sending 


Add  to  the  second  paragraph  after  "57  ...  authorized": 
"34  'no  circuit  or  channel  available';". 

Delete  "58  ...available"  and  "63  ...  unspecified"  from 
the  first  paragraph. 

Add  after  "57  ...  not  authorized":  "34  'no  circuit  or 
channel  available';"  in  the  first  paragraph. 

Add  the  following  at  the  end  of  section  5.1.5.2: 

"Other  Misdialing  Treatments 

The  Network  should  be  capable  of  recognizing  several 
types  of  misdialing.  If  network-provided  tones  and 
announcements  do  not  apply,  the  network  should 
initiate  call  clearing  in  response  to  a  misdialing  error. 
If  en-bloc  sending  has  been  used,  the  network  should 
send  a  RELEASE  COMPLETE  message  to  the  calling 
user  equipment.  If  overlap  sending  has  been  used,  the 
network  should  send  a  DISCONNECT  message  to  the 
calling  user  equipment.  The  initial  clearing  message 
should  contain  the  appropriate  cause  information,  as 
indicated  below,  and  the  signal  information  'reorder 
tone  on.'  If  tones  and  announcements  apply,  see 
section  5.3.4.1. 


—  Vacant  code:  National-specific  cause  4, 
'vacant  code.' 


—  Prefix  0  dialed  in  error:  National-specific 
cause  8,  'prefix  0  dialed  in  error.' 

—  Prefix  1  dialed  in  error:  National-specific 
cau.se  9  'prefix  1  dialed  in  error.' 

—  Prefix  1  not  dialed:  National-specific 
cause  10,  'prefix  1  not  dialed.'" 


Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 


Change  (a)  in  the  first  paragraph  to:  "In  an 
appropriate  call  control  message  when  a  state  change 
is  required  (i.e.,  CONNECT);  or,". 

Delete  from  the  second  paragraph  the  progress 
description  value  "4  'call  has  returned  to  the  ISDN'. 
Call  is  now  end-to-end  and  ISDN." 
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Section  5.1.7 

Call  confirmation  indication 


Section  5.2 

Call  establishment  at  the  destination  interface 
Section  5.2 

Call  establishment  at  the  destination  interface 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 

Section  5.2.2 
Compatibility  checking 

Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.2 

SETUP  message  delivered  by  broadcast  data  link 


Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.1 

Response  to  en-block  SETUP 
Section  5.2.5.3 

Called  user  clearing  during  incoming  call 
estabUshment 


Change  the  last  sentence  of  the  first  paragraph  to: 
"When  the  user  receives  the  ALERTING  message,  the 
user  shall  enter  the  Call  Delivered  state." 

Change  "ANSI  standard  T1.602"  to  "NIU  89-210"  in 
the  first  sentence  of  the  first  paragraph. 

Delete  the  third  paragraph  ("The  SETUP  message 
offered  ...  of  the  data  link  layer."). 

Delete  "Display,"  from  the  second  paragraph  "(e.g.. 
Display,  Low  layer  compatibility)." 

Add  the  following  to  the  end  of  second  paragraph. 
"In  general,  a  call  terminating  from  a  non-ISDN  line 
or  from  a  Public  Switched  Telephone  Network 
(PSTN)  trunk  should  be  offered  to  the  called  user 
equipment  with  the  3.1.  kHz  audio  bearer  capability." 

Change  "(e.g.,  for  DDI)"  to  "(e.g.,  7  digits)"  in  the 
second  sentence  of  the  third  paragraph. 

Delete  the  third  sentence  from  the  third  paragraph. 


Delete  the  third  paragraph. 


Delete  this  section. 


Combine  the  first  and  second  sentences  of  the  first 
paragraph  to:  "When  the  SETUP  message  is 
delivered  by  a  broadcast  data  link,  the  network  sends 
a  SETUP  message  with  the  Channel  identification 
information  element  indicating  a  specific  channel  with 
no  alternative  acceptable." 

Delete  "(see  Note)"  from  the  first  sentence  of  the  first 
paragraph. 

Delete  the  Note  after  the  first  paragraph. 

Delete  the  third  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  point-to-point  data  link 
..."). 

Delete  the  first  paragraph. 
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Section  5.2.5.3 

Called  user  clearing  during  incoming  call 
establishment 


Change  the  second  sentence  of  the  second  paragraph 
to:  "If  timer  T303  expires  (i.e.,  if  no  valid  message 
such  as  CALL  PROCEEDING,  ALERTING,  or 
CONNECT  has  been  received),  the  network  shall  take 
action  as  follows: 

a.  If  all  clearing  messages  received  from  the 
called  user  equipment  contain  cause  88, 
'incompatible  destination,'  the  call  should  be 
cleared  at  the  calling  ISDN  interface  with 
cause  18,  'no  user  responding  (location: 
public  network  serving  the  remote  user)'  and 
signal  'ring-back/audible  ringing  tone  on.' 


b.  If  one  or  more  call  clearing  messages 
with  cause  17,  'user  busy,'  have  been 
received  from  the  called  user  equipment,  the 
call  should  be  cleared  at  the  calling  ISDN 
interface  with  cause  17, 'user  busy  (location: 
user).'  The  signal  information  should  be 
coded  as  'busy  tone  on'  unless  an  audible 
ringing  tone  was  indicated  because  timer  T 
delay  (if  implemented)  previously  expired 
(see  sec.  5.2.1).  If  audible  ringing  is  being 
provided,  the  signal  information  should  be 
coded  as  'ring-back/audible  ringing  tone  on.' 

c.  If  no  call  clearing  messages  with  cause 
17  have  been  received  from  the  called  user 
equipment  and  at  least  one  call  clearing 
message  with  a  cause  other  than  88  has  been 
received,  the  call  should  be  cleared  at  the 
calling  ISDN  interface  with  cause  21,  'call 
rejected  (location:  user),'  and  signal  'ring- 
back/audible  ringing  tone  on.'." 


Section  5.2.5.3  Delete  the  last  sentence  from  the  second  paragraph: 

Called    user    clearing    during    incoming    call  "When  multiple  RELEASE  COMPLETE  ...  sent  to 

establishment  the  originating  user  (see  5.3)." 


Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 


Change  the  second  sentence  in  the  second  paragraph 
from  "If  an  ALERTING  message  has  been  received, 
...  any  other  cause  sent  by  a  called  user."  to  "If  an 
ALERTING  message  has  been  received,  the  cause 
sent  to  the  calling  user  shall  be  21  'call  rejected' 
(location:  user)." 
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Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 


Section  5.2.5.3.2 

DISCONNECT  received  after  expiry  of  timer  T312 


Section  5.2.5.3.2 

DISCONNECT  received  after  to  expiry  of  T312 


Section  5.2.5.4 
Call  failure 

Section  5.2.6 

Notification  of  interworking  at  the  terminating 
interface 

Section  5.2.7 
Call  accept 


Section  5.2.8 
Active  indication 


Change  the  third  sentence  in  the  second  paragraph 
from  "In  only  CALL  PROCEEDING  ...  sent  by  a 
called  user."  to  "If  only  CALL  PROCEEDING 
messages  have  been  received  from  called  users,  the 
cause  sent  to  the  caUing  user  shall  be  as  in  5.2.5.3." 

Change  the  second  sentence  in  the  third  paragraph 
from  "If  an  ALERTING  message  has  been  received, 
...  any  other  cause  sent  by  a  called  user."  to  "If  an 
ALERTING  message  has  been  received,  the  cause 
sent  to  the  calling  user  shall  be  21  'call  rejected' 
(location:  user)." 

Change  the  third  sentence  in  the  third  paragraph  from 
"If  only  CALL  PROCEEDING  ...  by  a  called  user"  to 
"If  only  CALL  PROCEEDING  messages  have  been 
received,  the  cause  sent  to  the  calling  user  shall  be  as 
in  5.2.5.3." 

Delete  all  occurrences  of  "(b)  ..."  (paragraphs  1,  3,  4) 
from  this  section. 

Delete  this  section. 


Add  to  the  end  of  the  second  paragraph:  "If  the 
CONNECT  message  is  the  first  response  to  the 
SETUP  message,  it  shall  contain  the  channel  ID 
information  element." 


Delete  the  last  paragraph  of  section  5.2.8  ("A  user 
which  has  ...  has  been  completed"). 
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Section  5.3.2 
Exception  conditions 


Add  the  following  before  the  Note  that  appears  at  the 

end  of  this  section. 

—  In  the  case  of  a  SETUP  message  sent  to 
the  user  via  the  broadcast  data  link,  if  a 
called  user  terminal  sends  a  first  response  to 
the  SETUP  message  after  timer  T303  has 
expired  (the  first  expiration  of  T303  is  the 
SETUP  message  should  not  be  retransmitted, 
and  the  second  expiration  of  T303  if  the 
SETUP  message  should  be  retransmitted  — 
note  that  the  SETUP  message  is 
retransmitted  only  when  no  response  is 
received  prior  to  the  first  expiry  of  T303, 
e.g.,  the  SETUP  message  should  not  be 
retransmitted  when  a  call  clearing  message(s) 
is  received  prior  to  the  first  expiry  of  T303), 
but  before  timer  T312  expires,  the  network 
should  clear  the  call  to  that  user  by  sending 
a  RELEASE  message.  This  message 
should  contain  cause  102,  'recovery  on  timer 
expiry'  (location:  public  network  serving  the 
local  user.). 


—  In  the  case  of  call  offering  via  the 
broadcast  data  link,  if  either  timer  T310  or 
T301  expires  at  the  called  user  interface,  the 
network  should  initiate  call  clearing  by 
sending  a  RELEASE  message  to  all  called 
user  equipment  responding  to  the  SETUP 
message  sent  by  the  network.  The 
RELEASE  message(s)  should  contain  cause 
102,  'recovery  on  timer  expiry'  (location: 
public  network  serving  the  local  user). 

—  If  a  call  attempt  is  unsuccessful  and  a 
speech,  3.1  kHz  audio  call  will  not  be 
immediately  cleared  because  inband  tones  or 
announcements  are  being  provided,  the 
network  should  send  the  calling  user  a 
PROGRESS  message  containing  progress 
message  containing  progress  indicator  8, 
'inband  information  or  appropriate  pattern 
now  available.'." 


Section  5.3.3 

Clearing  initiated  by  the  user 


Delete  the  last  Note  in  this  section. 
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Section  5.3.4.1 

Clearing  when  tones  or  announcements  provided 


Section  5.3.4.3 
Completion  of  clearing 


Add  the  following  at  the  end  of  section  5.3.4.1: 
"To  return  an  inband  tone  for  an  unsuccessful  speech, 
3.1.  kHz  audio  the  network  should  send  a 
PROGRESS  message  and  start  a  tone  timer  (value  to 
be  specified  by  network  provider)  in  anticipation  of 
the  user  initiating  the  clearing  process.  The 
PROGRESS  message  should  contain  the  cause  value 
indicated  in  the  detailed  procedures  of  Section  5.3, 
along  with  progress  indicator  8,  'inband  information 
or  appropriate  pattern  now  available.'  If  the  tone 
timer  expires,  the  network  should  initiate  call  clearing 
by  sending  the  calling  user  a  DISCONNECT  message 
containing  cause  102,  'recovery  on  timer  expiry.' 
The  network  should  then  continue  clearing  the 
connection  to  the  calling  user  equipment  according  to 
the  procedures  for  sending  a  DISCONNECT  message. 
The  procedures  described  above  also  apply  for 
returning  an  inband  announcement  for  an  unsuccessful 
speech,  3.1  kHz  audio  call,  with  the  exception  that  the 
tone  timer  is  not  used.  Inband  announcements  should 
not  be  timed;  however,  it  is  desirable  that  the  network 
Delete  an  inband  announcement  after  one  or  two 
message  cycles,  depending  on  the  number  specified 
by  the  network  provider.  In  removing  the  inband 
announcement,  the  network  should  follow  the  above 
procedures  for  expiration  of  the  tone  timer." 

Delete  the  last  Note  at  the  end  of  section  5.3.4.3. 


Section  5.5 
Restart  procedure 


Delete  this  section  including  all  subsecfions. 


Section  5.8 

Handling  of  error  conditions 


Change  "T1.607"  to  "Q.931"  in  the  first  sentence  of 
the  first  paragraph. 


Section  5.8.1 

Protocol  discrimination  error 

Section  5.8.3.1 

Invalid  call  reference  format 


Change  "T1.607"  to  "Q.931"  in  the  first  sentence  in 
the  first  paragraph. 

Change  the  second  paragraph  to:  "If  the  Call 
reference  information  element  octet  1,  bits  1  through 
4  indicates  a  length  greater  than  the  maximum  length 
supported  by  the  receiving  equipment  (see  4.3),  or  the 
Null  call  reference,  or  the  global  call  reference  is  used 
to  identify  a  call,  then  the  message  shall  be  ignored." 


Section  5.8.3.2 

Call  reference  procedural  errors 


Delete  item  "(f)  When  any  message  ...  shall  be 
relumed." 
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Section  5.8.4 

Message  type  or  message  sequence  errors 
Section  5.8.4 

Message  type  or  message  sequence  errors 


Section  5.8.4 

Message  type  or  message  sequence  errors 


Section  5.8.6.1 

Mandatory  information  element  missing 
Section  5.8.6.1 

Mandatory  information  element  missing 


Add  as  a  new  paragraph  "A  NOTIFY  message  may 
also  be  ignored  by  the  recipient."  after  the  first 
paragraph  (i.e.,  after  the  list  of  cause  values). 

Change  the  fourth  sentence  in  the  second  paragraph 
to:  "Whenever  the  network  receives  an  unexpected 
RELEASE  message,  the  network  shall:  disconnect  and 
release  the  B-channel;  clear  the  network  connection 
and  the  call  to  the  remote  user  with  cause  as  specified 
in  5.2.5.3,  or  cause  in  the  RELEASE  message  sent  by 
the  user.  If  no  cause  is  included,  cause  3 1  'normal, 
unspecified'  or  other  causes  as  specified  in  5.8.6.1; 
return  a  RELEASE  COMPLETE  message  to  the  user; 
release  the  call  reference;  stop  all  timers;  and  enter 
the  Null  state." 

Change  the  second  sentence  of  the  third  paragraph  to: 
"Whenever  the  network  receives  an  unexpected 
RELEASE  COMPLETE  message,  the  network  shall: 
disconnect  and  release  the  B-channel;  clear  the 
network  connection  and  the  call  to  the  remote  user 
with  the  cause  indicated  by  the  user  or,  if  not 
included,  cause  111  'protocol  error,  unspecified'  or 
other  causes  as  specified  in  5.8.6.1;  release  the  call 
reference;  stop  all  timers;  and  enter  the  Null  state." 

Change  the  beginning  of  the  first  sentence  in  the  third 
paragraph  to:  "When  a  DISCONNECT  message  (first 
clearing  message)  is  received  with 

Add  the  following  as  a  new  paragraph  after  the  third 
paragraph:  "As  an  option  the  network  shall  follow 
the  following  procedure.  The  DISCONNECT 
message  sent  to  the  network  should  contain  cause 
information.  If  the  network  receives  an  initial 
clearing  message  without  a  cause  information 
element,  it  should  accept  the  message,  disconnect  the 
associated  channel,  and  initiate  procedures  to  clear  the 
network  connection  and  the  call  to  the  remote  user. 
If  the  call  is  active  or  if  the  originating  user  cleared 
the  call  while  in  the  setup  phase,  the  network  should 
send  cause  16,  'normal  clearing  (location:  user)'  to 
the  remote  user.  It  should  send  cause  21,  'call 
rejected  (location:  user)'  if  the  terminating  user 
cleared  the  call  while  in  the  setup  phase.  The 
network  should  respond  to  the  user  initiating  call 
clearing  by  sending  a  RELEASE  message  containing 
cause  96,  'mandatory  information  element  is  missing 
(location:  pubUc  network  serving  the  local  user; 
diagnostic:  cause  information  element  identifier).'." 
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Section  5.8.6.2 

Mandatory  information  element  content  error 


Change  the  third  paragraph  to:  "When  a 
DISCONNECT  message  is  received  with  invalid 
content  of  the  Cause  information  element,  the  action 
taken  shall  be  the  same  as  if  a  DISCONNECT 
message  with  the  cause  missing  was  received  with  the 
exception  that  the  RELEASE  message  sent  on  the 
local  interface  contains  cause  100  'invalid  information 
element  contents'." 


Section  5.8.7.1 

Unrecognized  information  elements 


Section  5.8.8 
Data-link  reset 

Section  5.8.9 
Data-link  failure 

Section  5.8.9 
Data-link  failure 

Section  5.8.9 
Data-link  failure 


Section  5.8.10 

Status  enquiry  procedure 

Section  5.8.11 

Receiving  a  STATUS  message 
Section  5.8.11 

Receiving  a  STATUS  message 


Section  5.8.11 

Receiving  a  STATUS  message 


Section  5.8.11 

Receiving  a  STATUS  message 
Section  5.9 

User  notification  procedure 


Add  the  following  to  the  Note  after  the  first 
paragraph:  "or  not  implemented  by  the  receiver  in  a 
specific  message." 

Change  "ANSI  T1.607"  to  "NIU  90-301"  in  the  first 
sentence  of  the  first  paragraph. 

Change  "ANSI  T1.607"  to  "NIU  90-301"  in  the  first 
sentence  of  the  first  paragraph. 

Change  both  occurrences  of  "ANSI  T1.607"  in  the 
first  paragraph  bullet  b)  to  "NIU  90-301". 

Change  the  first  Note  after  the  first  paragraph  to:  "If 
the  transfer  mode  of  the  call  is  circuit-mode,  the  NIU 
90-301  entity  may  clear  the  calls." 

Delete  the  first  paragraph. 


Delete  "As  an  option:"  from  the  second  sentence  of 
the  third  paragraph  ("The  determination  ..."). 

Change  "a)"  in  the  third  paragraph  to:  "If  a  STATUS 
message  indicating  any  call  state  except  the  Null  state 
is  received  in  the  Null  state,  then  the  receiving  entity 
shall  send  a  RELEASE  COMPLETE  message  witb  a 
cause  101  'message  not  compatible  with  call  state'  or 
cause  81  'Invalid  Call  reference  value'  and  remain  in 
the  Null  state.  Otherwise,  no  action  shall  be  taken  on 
receipt  of  STATUS  unless  it  is  in  response  to 
STATUS  ENQUIRY." 

Delete  "b)  If  a  ..."  and  "c)  If  a  STATUS  message, 
indicating  the  Null  ...  into  the  Null  state."  after  the 
third  paragraph. 

Delete  the  last  three  paragraphs  and  the  last  Note  in 
this  section. 

Delete  this  section. 
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Section  6 

Packet  communication  procedures 


Change  sentence  to  "See  NIU  89-320". 


Section  9.1  Change  the  "T302/Default  time  out  value"  cell  from 

Timers  in  the  network  side  "10-15  s"  to  "16-24  s". 

Table  22  —  Timers  in  the  network  side 

Change  the  "T302/cause  for  start"  ceU  from  "SETUP 
ACKNOWLEDGE  sent.  Receipt  of  INFORMATION 
restarts  T302."  to  "SETUP  ACKNOWLEDGE  sent. 
Receipt  of  INFORMATION  not  containing  complete 
address  information  restarts  T302." 


Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 


Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 


Change  the  "T302/NORMAL  STOP"  cell  to:  "With 
sending  complete  indication,  or  potentially  complete 
address  information  received,  as  an  option,  the 
network  can  determine  that  a  potentially  complete 
code  has  been  received  following  the  receipt  of 
address  information,  and  the  network  could  use 
critical  interdigit  timing  (instead  of  T302)  to 
determine  whether  additional  digits  are  following. 
This  timing  could  be  3-5  seconds.  If  implemented, 
when  this  timer  expires,  a  complete  address  is 
assumed  and  the  procedures  in  section  5.1.5.2  shall  be 
followed.  In  an  INFORMATION  message  is  received 
and  the  critical  interdigit  timing  is  running,  it  shall  be 
stopped." 


Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 


Add  the  following  row  entry  for  Timer  "Tpot_comp" 
after  row  "T302": 


TIMER 
NUMBER 

DEFAULT 
TIME 
OUT 
VALUE 

STATE 
OF 

CALL 

CAUSES 

FOR 

START 

NORMAL  STOP 

AT  THE 

HRST 

EXPIRY 

AT  THE 

SECOND 

EXPIRY 

CROSS 
REFERENCE 

Tpot_comp 

3-5  s 

Overlap 
Sending 

Potentially 

complete 

address 

information 

received 

INFORMATION 
received 

Route 
call 

Timer 
not 

restarted 

* 

*  optional  —  as  an  option,  the  network  can  determine  that  a  potentially  complete  code  has  been  received  following  the  receipt  of 
iddress  information,  and  the  network  could  use  critical  interdigit  timing  (instead  of  T302)  to  determine  whether  additional  digits  are 
bllowing.  This  timing  could  be  3-5  seconds.  If  implemented,  when  this  timer  expires,  a  complete  address  is  assumed  and  the 
•rocedures  in  Section  5.1.5.2  shall  be  followed.  In  an  INFORMATION  message  is  received  and  the  critical  interdigit  timing  is 
unning,  it  shall  be  stopped." 
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Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Change  the  "T303/DEFAULT  TIME  OUT  VALUE" 
cell  from  "4s"  to  "2.5s". 


Change  the  "T303/NORMAL  STOP"  ceU  to  "ALERT, 
CONNECT,  or  CALL  PROCEEDING  received." 


Change  the  "T303/AT  THE  RRST  EXPIRY"  cell  to 
"Retransmit  SETUP;  re-start  T303." 


Delete  "Note  7"  from  the  "T308/AT  SECOND 
EXPIRY"  ceU. 


Change  "10s"  to  "5s"  in  the  "T310/DEFAULT  TIME 
OUT  VALUE"  cell. 


Delete  "Note  6"  from  the  "T310/DEFAULT  TIME 
OUT  VALUE"  cell. 


Delete  the  following  rows:  "T316",  "T317",  "T321". 


Delete  the  following  Notes:  3,  6,  7  at  the  end  of 
Table  22. 


Change  the  "T301/CROSS  REFERENCE"  cell  to 
"Note  3". 


Change  the  "T303/NORMAL  STOP"  cell  to  "SETUP 
ACKNOWLEDGE,  CALL  PROCEEDING  or 
RELEASE  COMPLETE  received". 

Delete  "(annex  D)"  from  the  "T303/AT  THE  HRST 
EXPIRY"  cell. 


Change  the  "T303/CROSS  REFERENCE"  cell  to 
"optional". 

Delete  "Note  5"  from  the  "T308/AT  THE  SECOND 
EXPIRY"  cell. 
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Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Delete  rows  "T310",  "T316",  "T317",  "T321". 


Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 


Delete  Notes  2  and  5  that  appear  at  the  end  of  table 
7. 


Annex  A 


Delete  this  section.  NOTE:  This  section  has  not 
been  addressed. 


Annex  B,  Section  B.3.1 

Compatibility  checking  with  addressing  information 


Annex  B,  Section  B.3.2 
Network  to  user  compatibility 


Change  the  second  sentence  under  "a)"  to:  "In  the 
case  of  a  mismatch,  the  user  shall  either  ignore  or 
reject  the  call." 

Change  the  last  sentence  in  this  section  to:  "If  a 
mismatch  is  detected,  then  the  user  shall  either  ignore 
or  reject  the  offered  call  using  cause  88  'incompatible 
destination'." 


Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capabihty  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  assured 
Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 


Delete  the  "point-to-point  data  Unk"  columns. 


Change  the  "Incompatible/Broadcast  data  link"  cell 
from  "Reject"  to  "Ignore  or  Reject". 


Delete  "Note  3"  from  the  "Incompatible/broadcast 
data  Unk"  column. 


Delete  the  reference  to  "Note  1"  from  the  last  column. 
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Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  B,  Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibility  not  assured 

Annex  C,  Section  C.l 
Introduction 

Annex  C,  Section  C.2 
Selection  not  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  C,  Section  C.3 
Selection  supported 

Annex  D 

Extension  for  symmetric  call  operation 
Annex  E 

Network-specific  facility  selection 


Change  "Accept  or  Reject"  to  "Accept,  Ignore,  or 
Reject"  in  the  Broadcast  Data  Link  column. 


Delete  Note  1  below  figure  B.3. 


Change  "will  reject  the  call  if  incompatible"  to  "may 
reject  the  call  if  incompatible"  in  Note  2  below  figure 
B.3. 


Delete  Note  3  ("Attempt  low  layer  compatibihty 
negotiation  (see  Annex  M).")  below  Figure  B.3. 


Delete  "optional"  from  the  first  paragraph. 


Delete  this  section. 


Change  the  first  sentence  of  the  first  paragraph  to: 
"The  user  identifies  the  selected  transit  network  in  the 
SETUP  message." 

Delete  the  second  and  third  paragraphs. 


Delete  the  fu-st  sentence  of  the  fourth  paragraph. 


Delete  the  last  sentence  in  the  sixth  paragraph. 


Delete  the  seventh,  eighth,  and  ninth  paragraphs. 


Delete  this  section. 


Delete  this  section. 


Annex  F  Delete  this  section. 

D-channel  backup  procedure 
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Annex  G,  Section  G.l 
Introduction 


Add  the  following  at  the  end  of  the  first  paragraph: 
"Section  4.5. 11  identifies  the  causes  supported  in  NIU 
90-301." 


Annex  G  Delete  the  following  sections: 

Cause  Definitions  •  Section  G.2.16  Cause  22  "number  changed" 

•  Section  G.3.2  Cause  38  "network  out  of  order" 

•  Section  G.3.7  Cause  45  "preemption" 

•  Section  G.3.8  Cause  46  "precedence  call  blocked" 

•  Section  G.3.9  Cause  47  "resource  unavailable, 
unspecified" 

•  Section  G.4.1  Cause  49  "quality  of  service 
unavailable" 

•  Section  G.4.4  Cause  58  "bearer  capability  no 
presently  available" 

•  Section  G.4.5  Cause  63  "service  or  option  not 
available,  unspecified" 

•  Section  G.5.2  Cause  66  "channel  type  not 
implemented" 

•  Section  G.5.4  Cause  70  "only  resu-icted  digital 
information  bearer  capability  is  available" 

•  Section  G.5.5  Cause  79  "service  or  option  not 
implemented,  unspecified" 

•  Section  G.6.2  Cause  82  "identified  channel  does 
not  exist" 

•  Section  G.6.4  Cause  91  "invalid  tfansit  network 
selection" 

•  Section  G.6.5  Cause  95  "invalid  message, 
unspecified" 


Annex  H 

Examples  of  Information  elements  coding 

Annex  H,  Section  H.l 
Introduction 


Change  the  status  of  this  section  from  "informative" 
to  "normative". 

Replace  the  first  and  second  paragraphs  with  the 
following:  "These  are  the  only  recognized  codings  of 
the  following  Information  Elements  for  circuit-mode 
services: 

—  Bearer  capability  information  element 

—  Channel  identification  information  element". 


Annex  H 

Examples  of  information  elements  coding 


Annex  H,  Section  H.3.1 

Basic  Interface,  circuit  mode,  B -channel 


Delete  the  following  figures  and  sections: 

•  Figure  "H.3  Coding  for  7  kHz  Audio" 

•  Figure  "H.6  Coding  for  synchronous  1472  kbit/s"; 

•  sections  H.3. 2  (Figures  H.9,  H.IO,  H.ll); 

•  H.3.3  (Figures  H.12  through  H.17); 

•  H.4  (Figures  H.18  through  H.21); 

Add  Attachment  D  of  this  document. 
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Annex  I 

Use  of  Progress  Indicators 
Annex  I 

Use  of  progress  indicators 
Annex  I 

Use  of  Progress  Indicators 
Annex  I 

Use  of  Progress  Indicators 
Annex  J 

Examples  of  Cause  Values  and  location  for  busy 
condition 

Annex  L 

low  layer  information  coding  principles 
Annex  M 

Low  layer  compatibility  Negotiation 
Annex  N 

Procedures  for  establishment  of  bearer  connection 
prior  to  call  acceptance 

Annex  O 

Optional  procedures  for  bearer  service  change 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.2 

Operator  system  access  requested  in  keypad  facility 
information  element 

Annex  P,  Section  P.2 

Operator  system  access  requested  in  keypad  facility 
information  element 


Change  the  status  of  this  Annex  from  "Informative" 
to  "Normative". 

Delete  the  fifth  paragraph  {"Progress  Indicator  4  ..."). 

Delete  "or  primary"  from  the  left  side  (between  TE 
and  ISDN)  of  Figure  I.l. 

Delete  "Basic  or"  from  the  right  side  (between  ISDN 
and  NT2)  of  Figure  I.l 

Change  "American  National  Standard  T1.607"  to 
"NIU  90-301"  in  the  first  sentence  of  the  first 
paragraph. 

Change  the  first  sentence  of  the  first  paragraph  to: 
"This  annex  is  part  of  NIU  90-301." 

Delete  this  annex. 


Delete  this  annex. 


Delete  this  annex. 


Delete  "optional"  from  the  first  sentence. 

Delete  "or  attendant  system"  from  the  end  of  the  first 
sentence  in  the  first  paragraph. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"These  procedures  apply  to  the  speech  and  3.1  kHz 
audio  bearer  services." 

Delete  "or  attendant  system"  from  the  first  sentence  in 
the  second  paragraph. 

Delete  "or  attendant  system"  from  the  first  sentence  of 
the  first  paragraph. 

Delete  "or  attendant  system"  from  the  last  sentence  of 
the  first  paragraph. 
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Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  P,  Section  P.3 

Use  of  the  operator  system  access  information 
element 

Annex  Q 

Responding  address  requirements  of  the  OSI  network 
layer  service 

Annex  R 

Application  of  the  Signal  Information  Element  to 
Tones  and  Alerting  Patterns 

Annex  R 

Application  of  the  Signal  Information  Element  to 
Tones  and  Alerting  Patterns 
Table  21  —  Tones 

Annex  S 

Comparison  of  CCITT  Recommendation  Q.931  to 
ANSI  Tl. 607 


Delete  "or  attendant  system"  from  the  first  sentence  of 
the  first  paragraph. 

Delete  "c)  Private/principal ...  SETUP  message."  from 
the  second  paragraph. 

Delete  "or  attendant  system"  from  the  third  paragraph. 


Delete  the  sixth  paragraph. 


Delete  this  annex. 


Change  the  status  of  this  Annex  from  "informative"  to 
"normative". 


Delete  the  following  rows:  2,  6,  8. 


Delete  this  annex. 
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Attachment  A 

(of  Appendix  A) 

1.  General 

1.1  Scope  and  Purpose 

This  Implementation  Agreement  specifies  a  minimal  subset  of  procedures  and  codepoints  from  the  American  National 
Standards  Tl.607-1990  (Ref.  [17])  for  the  establishment,  maintenance,  and  clearing  of  ISDN  connections  at  the  user- 
to-network  interface.  This  signalling  standard  is  used  to  support  the  circuit-switched  bearer  services  specified  in 
ANSI  standards  T1.603*. 

Terminals  are  not  required  to  support  all  services.  Switches  will  support  all  of  the  mandatory  protocols  and 
codepoints  in  this  implementation  agreement.  This  does  not  preclude  the  support  of  additional  services  and 
procedures.  However,  equipment  must  be  able  to  interoperate  with  equipment  supporting  only  this  minimal  subset. 

1.1.1  Definitions 

The  ANS  Tl.607-1990  (Ref.  [17])  assumes  that  procedures  apply  generically  to  ISDN  access  interfaces,  i.e.,  the 
document  does  not  distinguish  between  basic  and  primary  rates  access  interfaces.  In  addition,  there  are  no  references 
to  specific  applications  in  that  document.  The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit 
certain  procedures  to  be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
PBX.  Specifically,  two  classes  of  equipment  are  defined  on  the  basis  of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  public  network's  point 
of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the  public  network  and  ISDN 
terminals  or  telephones  connected  to  that  equipment).  For  example,  some  user  equipment  may  support  subtending 
Basic  Access  digital  subscriber  loops  and/or  analog  telephone  loops.  For  Class  I  equipment,  the  network  makes  no 
provision  for  such  an  arrangement  and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication. 
Conversely,  in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that  communication 
between  Class  II  equipment  (with  which  it  communicates  directly)  and  other  equipment  (with  which  the  network  does 
not  have  direct  contact)  may  occur.  As  an  example.  Class  II  equipment  may  support  digital  and/or  analog  subscriber 
loops.  Use  of  Class  II  equipment  also  involves  the  possibihty  of  having  interworking  occur  beyond  the  equipment 
with  which  the  network  has  direct  contact.  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network 
with  an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called  party 
respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking  notification  if  a  private  network 
exists  beyond  the  Class  II  equipment  and  interworking  to  a  non-ISDN  facility  within  that  network  takes  place.  When 
an  interface  is  associated  with  Class  I  equipment,  it  is  assumed  the  multiple  pieces  of  equipment  may  exist  and 
communicate  with  the  network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN- 
capable  and  is  considered  as  the  endpoint  of  the  communication.  Therefore,  interworking  notification  should  not  be 
accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  the  manner  in  which  a  SETUP  message  should  be  presented  to  the  user  equipment. 
When  Class  I  equipment  is  applied  on  a  particular  interfaces,  the  network  should  broadcast  the  SETUP  message 
associated  with  each  call  that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces 
of  user  equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP  messages 
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associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being  used.  Here,  a  single  piece 
of  user  equipment  is  assumed  to  be  involved  in  all  communication  with  the  network. 

To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply  to  all  ISDN  user 
configurations.  However,  in  cases  for  which  integrated  procedures  are  not  appropriate,  the  call  control  procedures 
associated  with  Equipment  Class  I  will  differ  from  those  associated  with  Equipment  Class  II.  Unless  otherwise 
noted,  the  assumption  should  be  that  a  particular  procedure/capability  should  be  provided  for  both  classes  of 
equipment  on  both  basic  and  primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits 
clarification  of  the  circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability  applies  only  to  a 
subset  of  four  possible  configurations  which  are  labeled  as  follows. 


Class  I  Class  II 


IB 

IIB 

IP 

IIP 

In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access  interfaces  (IB)  and/or 
primary  rate  access  interfaces  (IP).  Similarly,  a  capability  that  applies  to  Class  II  equipment  may  be  provided  on 
basic  access  interfaces  (IIB)  and/or  primary  rate  access  interfaces  (IIP). 

The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate  when  protocol  or 
procedures  are  only  expected  to  be  supported  for  a  particular  equipment  class  and/or  are  limited  to  a  particular  type 
of  interface,  i.e.,  basic  or  primary  rate  interface. 
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Attachment  B 

(of  Appendix  A) 

The  various  parts  of  the  called  party  number  information  element  should  be  coded  as  follows: 

—  Type  of  number  and  numbering  plan  (octet  3) 
Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1    International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  1  0  0  0  0  1    National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1  Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 
110  10  0  1    Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 


—  Digits  (octet  4,  etc.) 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

0  00  0 

0 

0 

1 

1 

0  00  1 

1 

0 

1 

1 

0  0  10 

2 

0 

1 

1 

0  0  11 

3 

0 

1 

1 

0  10  0 

4 

0 

1 

1 

0  10  1 

5 

0 

1 

1 

0  110 

6 

0 

1 

1 

0  111 

7 

0 

1 

1 

1000 

8 

0 

1 

1 

100  1 

9 

All  other  values  are  reserved 

Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  above. 

In  the  network  to  user  direction  (n  ->  u),  this  IE  will  be  always  signaled  in  the  SETUP  message,  and  public  network 
interfaces  will  use  only  one  codepoint:  local  number  in  ISDN.  For  private  networks,  this  EE  can  contain  the 
following  codepoints:  abbreviated  type  of  number,  and  private  numbering  plan,  and  extfa  digits  such  A,  B,  C,  and 
D  (as  per  IA5). 
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Attachment  C 

(of  Appendix  A) 


The  various  parts  of  the  calling  party  number  information  element  should  be  coded  as  described  below.  The 
numbering  plans  are  as  described  in  CCITT  Recommendations  E.164  or  X.121. 

—  Type  of  number  and  numbering  plan  (octet  3)  follows: 

Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1  International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  0  1  0  0  1  1  International  number  in  data  numbering  plan  (Rec.  X.121) 

0  1  0  0  0  0  1  National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1  Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 
110  10  0  1  Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 

—  Origin  of  number  and  presentation  status  (octet  3a)  follows: 

Bits 

7  6  5  4  3  2  1  Meaning 


0  0  0  0  0  0  0    Presentation  allowed  of  user-provided  number, 
number  not  screened 

0  0  0  0  0  0  1    Presentation  allowed  of  user-provided  number, 
number  passed  network  screening 

0  0  0  0  0  1  0    Presentation  allowed  of  user-provided  number, 
number  failed  network  screening 

0  0  0  0  0  1  1    Presentation  allowed  of  network-provided  number 

0  1  0  0  0  0  0    Presentation  prohibited  of  user-provided  number, 
number  not  screened 

0  1  0  0  0  0  1    Presentation  prohibited  of  user-provided  number, 
number  passed  network  screening 

0  1  0  0  0  1  0    Presentation  prohibited  of  user-provided  number, 
number  failed  network  screening 

0  1  0  0  0  1  1    Presentation  prohibited  of  network-provided  number 

1  0  0  0  0  1  1    Number  not  available 

All  other  values  are  reserved 

Notes 

1 —  ^When  octet  3a  is  omitted,  the  default  value  of  Number  Presentation  parameter  for  the  signaled  DN  value 
should  be  used,  if  it  is  available.  If  a  value  for  this  parameter  is  unavailable  (i.e.,  the  signaled  DN  value 
either  fails  screening  or  is  not  screened  by  the  SPCS),  the  presentation  parameter  value  of  the  default  DN 
should  be  used. 

2 —  Octet  3a,  bits  7  and  6  are  for  the  Presentation  Indicator;  bits  2  and  1  are  for  the  Screening  Indicator. 
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—  Digits  (octet  4,  etc.) 


Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  below: 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

0000 

0 

0 

1 

1 

0  00  1 

1 

0 

1 

1 

0  0  10 

2 

0 

1 

1 

0  0  11 

3 

0 

1 

1 

0  10  0 

4 

0 

1 

1 

0  10  1 

5 

0 

1 

1 

0  110 

6 

0 

1 

1 

0  111 

7 

0 

1 

1 

1000 

8 

0 

1 

1 

100  1 

9 

All  other  values  are  reserved 
Codings  At  Originating  Party  Interface 

The  calling  party  number  information  element  should  only  be  accepted  when  in  the  SETUP  message.  When 
the  type  of  number  and  numbering  plan  indicator  indicates  "local  number  in  the  ISDN  (E.164)  numbering 
plan,"  the  calling  party  number  information  element  should  contain  a  7-digit  local  number.  When  the  type 
of  number  and  numbering  plan  indicator  indicates  "national  number  in  the  ISDN  (E.164)  numbering  plan" 
the  calhng  party  number  information  element  should  contain  a  10-digit  national  number. 

In  the  network  to  user  direction  (n  ->  u),  the  coding  and  delivery  of  this  IE  depends  on  the  definition  of 
the  Calling  Line  ID  service.  For  private  networks,  this  IE  can  contain  the  following  codepoints:  abbreviated 
type  of  number,  and  private  numbering  plan,  and  extra  digits  such  as  A,  B,  C,  and  D  (as  per  IA5). 
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Attachment  D 

(of  Appendix  A) 

•  add  the  following  figures  to  section  H.3.1 


8        7        6        5        4  3  2        1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

1 

0 

0  1 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-1.  Channel  Bl  exclusive. 


8         7         6       5       4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

1  0 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-2.  Channel  B2  preferred. 
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8         7         6        5        4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

1 

0 

1  0 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-3.  Channel  B2  exclusive. 


8        7         6       5       4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

1  1 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-4.  Any  B-channel. 
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8        7         6        5        4  3  2         1  octet 


Channel  identification 

0 

0 

0 

1 

1 

0 

0  0 

Information  element  identifier 

0 

0 

0 

0 

0 

0 

0  1 

Length  of  the  channel  identification  contents 

1 

0 

0 

0 

0 

0 

0  0 

int 

int 

Pref/ 

D  ch. 

Ch.  sel. 

id 

type 

Excl 

id. 

Figure  H.7-5.  No  B-channel  Indicated. 
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NIU  90-302 
Implementation  Agreement 
of  the  North  American  ISDN  Users'  Forum 

Layer  3  Signalling  Specification  for  the 
Minimal  Set  of  Circuit-Switched  Bearer  Services  for 
the  ISDN  Class  II  Primary  Rate  Interfaces. 

Baseline  Text 

American  National  Standard  T 1.607- 1990: 
Integrated  Services  Digital  Network  (ISDN)  — 
Layer  3  Signalling  Specification  for 
Circuit-Switched  Bearer  Service  for 
Digital  Subscriber  Signalling  System  Number  I  (DSSl). 

Base  Standards 
CCITT  Recommendation  Q.931  (1988): 
ISDN  User-Network  Interface  Layer  3 
Specification  For  Basic  Call  Control. 

ANSI  Tl. 607- 1990 
ANSI  Tl.603-1990*: 
Integrated  Services  Digital  Network  (ISDN)  — 
Minimal  Set  of  Bearer  Services  for 
the  Primary  Rate  Interface. 

B.l  Abstract 

This  Implementation  Agreement  specifies  procedures  for  establishing,  maintaining,  and  clearing  connections  at  the 
Integrated  Services  Digital  Network  (ISDN)  user-network  interfaces  identified  as  Class  II  PRJ,  and  are  mandatory 
for  the  support  of  the  minimal  set  of  circuit-switched  bearer  services  specified  by  ANSI  Tl.603-1990'  Integrated 
Services  Digital  Network  (ISDN)  —  Minimal  Set  of  Bearer  Services  for  the  Primary  Rate  Interface,  (Ref  [14]). 
Procedures  for  circuit-mode  digital,  circuit-mode  speech  and  circuit-mode  voiceband  data  bearer  services  are  as 
specified  in  the  baseline  text  ANS  Tl.607-1990,  Integrated  Services  Digital  Network  (ISDN)  —  Digital  Subscriber 
Signalling  System  Number  1  (DSSl)  — Layer  3  Signalling  Specification  for  Circuit-Switched  Bearer  Service,  (Ref 
[17]),  as  further  resolved  by  this  agreement.  The  packet-mode  data  service  is  included  in  this  document  as  a  bearer 
service.  Procedures  for  the  packet-mode  bearer  service  will  be  detailed  in  another  document. 
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B.2  Introduction 


The  original  implementation  agreement  (NUJ  90-302)  was  reached  by  marking  up  the  text  of  ANS  Tl. 607-1990, 
(Ref.  [17])  to  reflect  the  clarifications  of  text  and  selection  of  options.  This  appendix  translates  the  implementation 
agreement  markup  into  a  listing  of  these  clarifications  and  selections,  (i.e.,  this  appendix  Usts  the  differences  (the 
"delta")  between  the  implementation  agreement  marked  up  ANS  Tl.607-1990,  and  the  original  text  of  ANS  T1.607- 
1990). 

B.3  NIU  90-302  Delta  List" 

The  lA  has  adopted  the  ANS  Tl.607-1990'"  (Ref  [17])  standard  with  the  following  clarifications  of  the  text,  and 
selection  of  options: 


ANS  Tl.607-1990 
SECTIONyTABLE  NUMBER/NAME 


Section  1.1 
Scope  and  Purpose 

Section  2.1.1.3 
Overlap  Sending  (U2) 

Section  2.1.2.3 
Overlap  Sending  (N2) 

Section  2.1.2.14 
Call  Abort  (N22) 

Section  3.1 

Table  1  —  Messages  for  circuit-mode  connection 
control 

Section  3.1 

Table  1  —  Messages  for  circuit-mode  connection 
control 


IMPLEMENTATION  AGREEMENTS  - 
CLARIFICATION  OF  TEXT  AND 
SELECTION  OF  OPTIONS 

Replace  this  section  with  Attachment  A  of  this 
document. 

Delete  this  section. 


Delete  this  section. 


Delete  this  section. 


Delete  the  following  message  and  reference: 
"INFORMATION  3.1.6". 


Delete  the  following  message  and  reference:  "SETUP 
ACKNOWLEDGE  3.1.12". 


Section  3.1  Change  "NOTIFY    3.1.7"  to  "NOTIFY*". 

Table  1  —  Messages  for  circuit-mode  connection 

control 


"Note  that  this  Delta  List  was  developed  in  "good  faith"  by  NIST  as  a  simple  equivalent  representation  of  the 
actual  agreements.  It  has  been  reviewed  and  approved  by  the  editors  of  the  Signalling  Working  Group  as  per 
recommendation  of  the  Executive  Steering  Committee. 

"'These  documents  can  be  purchased  from:  American  National  Standards  Institute,  11  West  42nd  Street,  New 
York,  NY  10036.  j 

3.2  NIU-Forum  Agreements  on  ISDN 

I 


i 


Section  3.1 

Messages  for  circuit-mode  connection  control 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  -  ALERTING  message  content 

Section  3.1.1 
ALERTING 

Table  2  —  ALERTING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.2 

CALL  PROCEEDING 

Table  3  —  CALL  PROCEEDING  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Add  the  following  footnote  below  Table  1  "*  See 
section  5.8.4  for  treatment  of  this  message." 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 

Delete  Notes  4,  5,  6. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Type"  cell  from 
"0(Note  D"  to  "M". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  rows 

•  "Progress  indicator"; 

•  "Display". 

Delete  Notes  1,  2,  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 
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Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 


Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 

Section  3.1.3 
CONNECT 

Table  4  —  CONNECT  message  content 
Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.4 

CONNECT  ACKNOWLEDGE 

Table  5  —  CONNECT  ACKNOWLEDGE  message 

content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.5 
DISCONNECT 

Table  6  —  DISCONNECT  message  content 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Low  layer  compatibility". 

Change  Note  3  to:  "Included  in  the  event  of 
interworking." 

Delete  Notes  4,  5,  6,  7,  8,  9. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 


Delete  Notes  1,  2,  3. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  from  "4-32"  to  "4-10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"' 

•  "Connected  Number"; 

•  "Connected  subaddress". 


Section  3.1.5  Delete  Notes  1,  2,  3,  4,  and  5. 

DISCONNECT 

Table  6  —  DISCONNECT  message  content 

Section  3.1.6  Delete  this  section. 

INFORMATION 
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Section  3.1.7 
NOTIFY 


Delete  this  section. 


Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.8 
PROGRESS 

Table  9  —  PROGRESS  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 


Section  3.1.9 
RELEASE 

Table  10  —  RELEASE  message  content 

Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2,  4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal". 

Delete  Notes  2,  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Cause/Length"  cell  from  "2-32"  to  "2,  4- 
10". 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  5,  6,  7. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Section  3.1.10  Change  the  "Cause/Length"  cell  from  "2-32"  to  "2,  4- 

RELEASE  COMPLETE  10". 
Table  1 1  —  RELEASE  COMPLETE  message  content 
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Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.10 
RELEASE  COMPLETE 

Table  1 1  —  RELEASE  COMPLETE  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Delete  the  following  rows: 

•  "Display"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress". 

Delete  Notes  3,  4,  5,  6,  7. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  the  following  rows: 

•  "Repeat  indicator"; 

•  "Display"; 

•  "Keypad  facihty"; 

•  "Signal". 

Change  the  "Bearer  capability/Type"  cell  from 
"M(Note  2)"  to  "M". 


Change  the  "Bearer  capability/Length"  cell  from  "4- 
13"  to  "4-8". 


Change  the  "Channel  identification/Type"  cell  from 
"0(Note  3)"  to  "M". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "5-6". 


Change  the  "Network  specific  faciUties/Length"  cell 
from  "2-*"  to  "2-32". 


Change  the  "Calling  party  number/Length"  cell  from 
"2-*"  to  "2-19". 


Change  the  "Called  party  address/Length"  cell  from 
"2-*"  to  "2-18". 
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Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 

Section  3.1.11 
SETUP 

Table  12  —  SETUP  message  content 


Section  3.1.12 

SETUP  ACKNOWLEDGE 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 


Change  the  "Transit  network  selection/Length"  cell 
from  "2-*"  to  "2-7". 


Change  the  "High  layer  capability/Length"  cell  from 
"2-4"  to  "2-5". 

Delete  Notes  1,  2,  3,  6,  7,  8,  9. 


Change  Note  4  to:  "Included  in  the  event  of 
interworking." 

Change  the  first  sentence  of  Note  12  to:  "The  called 
party  number  information  element  is  included  by  the 
user  ....". 

Change  the  first  sentence  of  Note  20  to:  "This 
information  applies  to  speech  and  3.1  kHz  audio 
bearer  services." 

Add  the  following  to  the  end  of  Note  13:  "The 
network  should  transport  this  IE  transparently.  This 
IE  is  optional  on  the  user  side." 

Add  the  following  to  the  end  of  Note  15:  "The 

network  should  transport  this  IE  transparently.  This 
IE  is  optional  on  the  user  side.  The  total  length  is  2 
to  16  octets." 

Add  the  following  to  the  end  of  Note  16:  "The 

network  should  transport  this  IE  transparently.  This 
IE  is  optional  on  the  user  side." 

Add  the  following  to  the  end  of  Note  17:  "The 
network  will  treat  this  IE  on  sending  and  receiving  as 
described  in  the  User-User  supplementary  service 
Implementation  Agreement." 

Delete  this  section. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 
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Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.13 
STATUS 

Table  14  —  STATUS  message  content 

Section  3.1.14 
STATUS  ENQUIRY 


Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.1.14 
STATUS  ENQUIRY 

Table  15  —  STATUS  ENQUIRY  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 

Section  3.2.1 
RESTART 

Table  17  —  RESTART  message  content 
Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 


Change  the  "Cause/Length"  cell  from  "4-32"  to  "4- 
10". 


Delete  row  "Display". 


Delete  Notes  1,  2. 


Change  the  first  sentence  to:  "This  message  is  sent 
by  the  user  or  the  network  during  the  active  state  to 
solicit  a  STATUS  message  from  the  peer  layer  3 
entity." 

Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Delete  row  "Display". 


Delete  Notes  1,  2. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  row  "Display". 


Delete  Notes  3,  4. 


Change  the  "Call  reference/Length"  cell  from  "2-*"  to 
"2-3". 


B-8 


NIU-Forum  Agreements  on  ISDN 


Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  3.2.2 

RESTART  ACKNOWLEDGE 

Table  18  —  RESTART  ACKNOWLEDGE  message 

content 

Section  4.2 

Protocol  discriminator 


Section  4.2 

Protocol  discriminator 

Figure  2  —  Protocol  Discriminator 

Section  4.2 

Protocol  discriminator 

Table  19  —  Protocol  Discriminator 

Section  4.3 
Call  reference 


Section  4.3 
Call  reference 

Section  4.3 
Call  reference 

Figure  4  —  Dummy  call  reference 

Section  4.3 
Call  reference 


Section  4.3 
Call  reference 

Section  4.4 
Message  type 

Table  20  —  Message  types 


Change  the  "Channel  identification/Length"  cell  from 
"2-*"  to  "2,  5-6". 


Delete  row  "Display". 


Delete  Notes  3,  4. 


Add  the  following  sentence  after  the  first  sentence  in 
die  second  paragraph:  "The  only  value  supported  for 
call  control  messages  is  described  below  in  Figure  2." 

Change  "ANSI  T1.607"  to  "Q.931". 


Change  "ANSI  T1.607"  to  "Q.931"  in  row  "0000 
1000". 


Change  the  third  paragraph  ("At  a  minimum  ...")  to: 
"At  a  minimum,  all  networks  and  users  must  be  able 
to  support  a  call  reference  value  of  one  and  two  octets 
for  a  primary  rate  interface." 

Delete  the  first  sentence  of  the  fourth  paragraph  "As 
a  network  ...  also  be  supported." 

Change  "Figure  4.  Dummy  call  reference"  to  "Figure 
4.  Dummy  call  reference  *". 

Add  the  following  footnote  after  Figure  4:  "*The 
dummy  call  reference  is  not  supported  for  primary 
rate  Class  II  circuit-switched  calls." 

Delete  Note  1  ("The  call  reference  ...  ")  at  the  end  of 
the  section. 

Delete  the  following  rows: 

•  "SETUP  ACKNOWLEDGE"; 

•  "INFORMATION". 
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Section  4.4 
Message  type 

Table  20  —  Message  types 

Section  4.5.1 
Coding  rules 

Section  4.5.1 
Coding  rules 

Figure  7  —  Formats  of  information  elements 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Add  the  following  to  the  end  of  row  "NOTIFY": 
"(see  sec.  5.8.4  for  treatment  of  this  message  type)." 


Delete  the  second,  third,  and  fourth  sentences  from 
the  fourth  paragraph. 

Delete  figure  (b)  Single  octet  information  element 
format  (type  2). 


Delete  the  following  rows: 

•  "Repeat  indicator"; 

•  "Notification  indicator"; 

•  "Display"; 

•  "Keypad  facility"; 

•  "Signal"; 

•  "Connected  number"; 

•  "Connected  subaddress"; 

•  "Escape  for  extension". 

Delete  reference  to  "(Note  6)"  from  "Bearer 
capability"  row. 


Change  the  "Bearer  capability/Max  length"  cell  from 
"13"  to  "8". 


Change  the  "Cause/Max  length"  cell  from  "32"  to 
"10". 


Change  the  "Cause/Max  no  of  occurrences"  cell  from 
"3"  to  "2". 


Change  the  "Channel  identification/Max  length"  cell 
from  "(Note  4)"  to  "6". 


Change  the  "Network-specific  facilities/Max  length" 
cell  from  "(Note  4)"  to  "32". 


Change  the  "Network-specific  facilities/Max  no.  of 
occurrences"  cell  from  "4"  to  "2". 
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Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Change  the  "Calling  party  number/Max  length"  cell 
from  "(Note  4)"  to  "19". 


Change  the  "Called  party  number/Max  length"  cell 
from  "(Note  4)"  to  "18". 

Delete  reference  to  "(Note  2)"  from  "Transit  network 
selection"  row. 

Change  the  "Transit  network  selection/Max  length" 
cell  from  "(Note  4)"  to  "7". 


Section  4.5.1  Delete  "4"  from  the  "Transit  network  selection/Max 

Coding  rules  no,  of  occurrences"  cell. 

Table  21  —  Information  element  identifier  coding 


Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 

Section  4.5.1 
Coding  rules 

Table  21  —  Information  element  identifier  coding 


Change  the  "High  layer  compatibiHty /Max  length"  cell 
from  "4"  to  "5". 

Delete  Notes  3,  4,  6. 


Section  4.5.1  Delete  this  figure. 

Coding  rules 

Figure  8  —  Information  element  format  using  escape 
for  extension 

Section  4.5.2  Change  "T1.608"  to  "NIU  89-320"  in  the  first  bullet 

Extensions  of  codesets  in  the  fourth  paragraph. 
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Section  4.5.2 
Extensions  of  codesets 


Replace  the  tenth  paragraph  ("Codeset  6  ...")  with  the 
following: 


Section  4.5.3 

Locking  shift  procedure 

New  codeset  identification  table 

Section  4.5.4 

Non-locking  shift  procedures 
Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  table 

Section  4.5.4 

Non-locking  shift  procedures 
Temporary  codeset  identification  table 

Section  4.5.5 
Bearer  Capability 

Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 


"Codeset  6  is  reserved  for  information  elements 
specific  to  the  local  network  (either  public  or  private). 
These  information  elements  can  appear  in  a  call 
establishment  (i.e.,  SETUP,  ALERTING,  or 
CONNECT)  or  first  clearing  message.  As  such,  they 
do  not  have  significance  across  a  national  or 
international  boundary.  For  these  two  cases,  codeset 
6  information  elements  shall  be  handled  according  to 
the  procedures  for  unrecognized  information  elements 
(see  sec.  5.8.7.1)  beyond  the  local  network  boundary. 
Inside  a  private  local  network  recognized  codeset  6 
information  elements  shall  be  consumed,  manipulated, 
or  passed  transparently  according  to  the  rule  for  that 
information  element.  Across  the  boundary  between 
local  networks  (e.g.,  a  public  and  a  private  network), 
recognized  codeset  6  information  elements  shall  be 
consumed  and  manipulated  according  to  the  rule  for 
that  information  element.  Inside  a  private  local 
network,  unrecognized  codeset  6  information  elements 
may  be  passed  transparently.  Across  the  boundary 
between  a  private  local  network  and  a  public  local 
network,  unrecognized  codeset  6  information  elements 
shall  be  either  treated  as  per  section  5.8.7.1  or  passed 
transparently  if  a  bilateral  agreement  exists." 

Change  "T1.608"  to  "NIU  89-320"  for  codeset  5. 


Delete  "a)  process  the  nonblocking  ...  as  described 
below"  from  the  second  paragraph. 

Change  "T1.607"  to  "NIU  90-302"  for  codeset  0. 


Change  "T1.608"  to  "NIU  89-320"  for  codeset  5. 


Change  "13  octets"  to  "8  octets"  in  the  second 
sentence  ("The  maximum  length  ...")  of  the  second 
paragraph. 

Change  octet  4,  bit  8  from  "0/1"  to  "1". 
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Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 


Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  Capability 

Figure  11  —  Bearer  capability  information  element 

Section  4.5.5 
Bearer  Capability 

Information  transfer  capability  (octet  3)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Information  transfer  rate  (octets  4  and  4b)  coding 

Section  4.5.5 
Bearer  Capability 

Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 


Delete  the  following  octets: 

•  4a; 

•  4b; 

•  5b  (Note  2); 

•  5b  (Note  3); 

•  5c; 

•  5d. 

Change  octet  5a,  bit  8  from  "0/1"  to  "1". 


Delete  Notes  1,  2,  3. 


Add  the  following  after  Note  4:  "5  Octets  6  and  7 
are  included  for  information  only.  The  coding  and 
application  of  these  octets  are  included  in  another 
document." 

Delete  row  "10001  7  kHz  audio". 


Change  the  title  to  "Information  transfer  rate  (octet 
4)". 


Delete  the  following  rows:  "10011  384  kbit/s", 
"10100  1472  kbit/s  (Note  2)",  "10101  1526  kbit/s". 


Change  Note  1  to:  "The  bearer  capability  is 
bidirectional  symmetric  at  the  information  transfer 
rate  specified  in  octet  4." 

Delete  Note  2. 


Delete  all  codings  and  text  referring  to  octet  4a 
(structure,  configuration,  establishment)  and  octet  4b 
(symmetry). 

Delete  "and  optionally  octets  5b,  5c,  and  5d  as 
defmed  below."  from  row  "00001". 
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Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

User  information  layer  1  protocol  (octet  5)  coding 

Section  4.5.5 
Bearer  Capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 

Synchronous/asynchronous  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 
Negotiation  (octet  5a)  coding 

Section  4.5.5 

Bearer  Capability 

User  rate  (octet  5a)  coding 

Section  4.5.5 
Bearer  Capability 


Section  4.5.5 
Bearer  Capability 


Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 


Delete  "and  G,725  7  kHz  audio"  from  row  "00101". 


Delete  rows  "00111"  and  "01000". 


Delete  Note  2. 


Delete  row  "1  asynchronous". 


Delete  the  second  and  third  sentences  from  the  Note. 


Delete  row  "1  In-band  negotiation  possible". 


Delete  all  rows  except  row  "01111  56  kbit/s  CCITT 
Recommendation  V.6". 


Delete  all  text  relating  to  octet  5b  (i.e.,  sections 
labeled  "Octet  5b  for  CCITT  Recommendation  V.lOO 
or  X.30  rate  adaption"  and  "Octet  5b  for  CCITT 
Recommendation  V.120  rate  adaption"). 

Delete  all  codings  and  text  referring  to  octets  5c 
(number  of  data  bits  excluding  parity  bit,  parity 
information)  and  5d  (duplex  mode,  modem  type). 

Delete  row  "000010  U2  —  overiap  sending". 


Add  the  following  column  to  the  right  of  the  coding: 
Symmetric  States* 

50  —  Null 

51  —  Call  Initiated 

53  —  Outgoing  Call  Proceeding 

54  —  Call  Delivered 

56  ■—  Call  Present 

57  —  Call  Received 

58  —  Connect  Request 

59  —  Incoming  Call  Proceeding 
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Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.6 
Call  state 

Call  state  value  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 


Section  4.5.7 

Called  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.7 
Called  party  number 

Numbering  Plan  Identification  (octet  3)  coding 


Section  4.5.7 
Called  party  number 

Numbering  plan  identification  (octet  3)  coding 


Section  4.5.7 
Called  party  number 


Section  4.5.9 
Calling  party  number 


510  —  Active 

511  —  Disconnect  Request 

512  —  Disconnect  Indication 
S19  —  Release  Request 

Add  the  following  after  the  coding:  "*Note  —  For 
Symmetric  states  see  Annex  D." 

Delete  "N22  —  Call  abort"  from  the  "010110/ 
Network  State"  cell. 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  18  octets." 

Delete  the  following  rows: 

•  "Oil  network  specific  number"; 

•  "ill  reserved  for  extension". 

Change  the  end  of  Note  2  to:  "this  information 
element  cannot  be  used  in  combination  with  Operator 
System  Access  or  Transit  Network  Selection 
information  elements." 

Delete  Note  4. 


Delete  the  following  rows: 

•  "0011  data  numbering  plan"; 

•  "0100  telex  numbering  plan"; 

•  "1111  reserved  for  extension". 

Change  "c)"  under  the  Note  to:  "this  information 
element  cannot  be  used  in  combination  with  Operator 
System  Access  or  Transit  Network  Selection 
information  elements." 

Add  Attachment  B  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering/dialing  plan." 

Change  the  second  paragraph  from  "The  maximum 
length  of  this  information  element  is  network 
dependent."  to  "The  maximum  length  of  this 
information  element  is  19  octets." 


NIU-Forum  Agreements  On  ISDN 


B-15 


Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 

Calling  party  number 

Type  of  number  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 

Numbering  Plan  Identification  (octet  3)  coding 

Section  4.5.9 
Calling  party  number 


Section  4.5.11 
Cause 


Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Figure  17  —  Cause  information  element 

Section  4.5.11 
Cause 

Recommendation  (octet  3a)  coding 

Section  4.5.11 
Cause 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Delete  the  following  rows: 

•  "Oil  network  specific  number"; 

•  "111  reserved  for  extension". 

Delete  Note  4. 


Delete  the  following  rows: 

•  "0100  telex  numbering  plan"; 

•  "1111  reserved  for  extension". 

Add  Attachment  C  of  this  document  after  the 
following: 

"Number  digits  (octets  4,  etc.) 

This  field  is  coded  with  ASCII  characters, 
according  to  the  formats  specified  in  the  appropriate 
numbering/dialing  plan." 

Change  the  second  sentence  of  the  first  paragraph  to: 
"The  maximum  length  of  this  information  element  is 
10  octets." 

Change  octet  3,  bit  8  from  "0/1"  to  "1". 


Delete  octet  3a. 


Delete  the  Note  under  the  figure. 


Delete  this  coding  and  Notes  1  and  2. 


Add  the  following  sentence  to  the  end  of  the 
paragraph  following  "Diagnostics  (octet  5)":  "If  more 
than  one  IE  is  identified  in  a  diagnostic,  they  should 
be  ordered  as  Es  normally  appear  in  a  message." 

Change  the  "unallocated  (unassigned)  number/ 
diagnostics"  cell  to  "Not  used". 

Change  the  "no  route  to  specified  transit  network/ 
diagnostics"  cell  to  "Not  used". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Change  the  "no  route  to  destination/diagnostics"  ceil 
to  "Not  used". 


Change  "normal  call  clearing/diagnostics"  cell  to  "Not 
used". 


Change  the  "user  busy/diagnostics"  cell  to  "(see  Note 
10)". 


Change  the  "call  rejected/diagnostics"  cell  to  "Not 
used". 


Delete  the  "number  changed/diagnostics"  cell. 


Delete  the  following  rows: 

•  "non-selected  user  clearing"; 

•  "network  out  of  order"; 

•  "resource  unavailable,  unspecified"; 

•  "quality  of  service  unavailable"; 

•  "only  restricted  digital  information  bearer  capability 
is  available"; 

•  "service  or  option  not  implemented,  unspecified"; 

•  "invalid  transit  network  selection"; 

•  "invalid  message,  unspecified". 

Change  the  "No  circuit/channel  available/diagnostics" 
cell  to  "(see  Note  10)". 


Delete  reference  to  "(see  Note  6)"  in  the  "access 
information  discarded/diagnostics"  cell. 


Add  "(see  Note  10)"  to  the  "requested  circuit  or 
channel  not  available/diagnostics"  cell. 


Delete  the  corresponding  cell  in  the  "diagnostics" 
column  for  the  following  rows: 

•  "requested  facility  not  subscribed"; 

•  "bearer  capability  not  authorized"; 

•  "bearer  capability  not  presently  available"; 

•  "channel  type  not  implemented"; 

•  "requested  facility  not  implemented". 
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Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 


Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 
Cause  table 

Section  4.5.11 
Cause 

Figure  18  —  Coding  of  the  diagnostic  field  for  causes 
57,  58  and  65. 

Section  4.5.11 
Cause 

Section  4.5.12 
Channel  identification 


Section  4.5.12 
Channel  identification 


Change  the  "bearer  capability  not  implemented/ 
diagnostics"  cell  to  "Not  used". 


Change  the  "identified  channel  does  not  exist/ 
diagnostics"  cell  to  "Not  used". 

Delete  the  "incompatible  destination/diagnostics"  cell. 


Delete  the  reference  to  "(see  Note  6)"  in  the 
"mandatory  information  element  is  missing/ 
diagnostics"  cell. 

Change  the  "informadon  element  non-existent  or  not 
implemented/diagnostics"  cell  to  "Information 
element  idendfier(s)  (see  Note  8)". 


Change  die  "invalid  information  element  contents/ 
diagnostics"  cell  to  "Information  element 
identifier(s)". 

Change  the  "recovery  on  timer  expiry/diagnostics" 
cell  to  "Not  used". 


Delete  die  following  Notes:  2,  3,  4,  5,  6,  7,  9,  11,  12. 


Delete  this  figure  and  Notes  1  and  2  appearing  below 
it. 


Delete  all  text  referring  to  octets  5  (attribute  number), 
5a  (rejected  attribute),  and  5b  (available  attribute). 

Change  die  last  sentence  in  die  first  paragraph  to: 
"The  default  maximum  length  for  this  information 
element  is  6  octets." 

Delete  the  second  paragraph. 
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Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 

Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Change  octet  3.1,  bit  8  from  "0/1"  to  "1". 


Delete  the  reference  to  "Note  2"  of  octet  3.2. 


Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Delete  the  references  to  "(Note  2)"  and  "Note  4"  in 
octet  3.3. 


Section  4.5.12  Delete  the  last  sentence  of  Note  1. 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12  Delete  Notes  2  and  4. 

Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Section  4.5.12 
Channel  identification 

Figure  19  —  Channel  identification  information 
element 


Add  the  following  to  the  end  of  Note  3: 
completeness,  a  pointer  to  slot  map  is  shown, 
not  supported  for  this  lA." 


Section  4.5.12 

Channel  identification 

Interface  identifier  present  (octet  3)  coding 

Section  4.5.12 
Channel  identification 
Interface  type  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 

Section  4.5.12 
Channel  identification 

Information  channel  selection  (octet  3)  coding 


Change  row  the  last  row  ("1")  to:  "1  Interface 
explicitly  identified  in  octet  3.1." 


Delete  the  following  row:  "0  basic  interface". 


Delete  the  column  "basic  interface". 


Delete  the  last  two  rows  ("10"  and  "11"). 


Delete  Note  3. 
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Section  4.5.12 

Channel  identification 

Interface  identifier  (octet  3.1)  coding 

Section  4.5.12 

Channel  identification 

Coding  standard  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 
Number/map  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Channel  type/map  element  type  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Channel  type/map  element  type  (octet  3.2)  coding 

Section  4.5.12 
Channel  identification 

Section  4.5.12 
Channel  identification 


Section  4.5.13 
Connected  number 

Section  4.5.14 
Connected  subaddress 

Section  4.5.15 
Display 

Section  4.5.16 

High  layer  compatibility 

Section  4.5.17 
Keypad  facility 

Section  4.5.18 

Low  layer  compatibility 

Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 


Delete  the  second  sentence  ("At  subscription  time 
..."). 


Delete  row  "  1  0  National  Standard  ..." 


Delete  the  last  row. 


Delete  the  last  three  rows. 


Delete  the  Note. 


Delete  all  text  and  Figure  20  referring  to  "Slot  map 
(octet  3.3)". 

Add  the  following  at  the  end  of  the  section:  "Note  — 
In  the  network  to  user  direction  (n  ->  u),  the 
terminating  PRI  will  allow  channel  negotiation.  The 
network  will  support  offering  calls  with  preferred  B- 
channel  and  the  user  responds  specifying  the  channel 
to  be  used  for  the  call." 

Delete  this  section. 


Delete  this  section. 


Delete  this  section. 


Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  five  octets." 

Delete  this  section. 


Delete  the  second  paragraph. 


Delete  the  last  row. 
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Section  4.5.18 

Low  layer  compatibility 

Negotiation  indicator  (octet  3a)  coding 

Section  4.5.18 

Low  layer  compatibility 

User  information  layer  3  protocol  (octet  7)  coding 

Section  4.5.19 
Network-specific  facilities 


Section  4.5.19 
Network-specific  facilities 

Section  4.5.19 
Network-specific  facilities 

Section  4.5.20 
Notification  indicator 


Delete  Note  1. 


Change  "ANSI  T1.607"  to  "NIU  90-302"  in  the  first 
row. 


Change  the  second  sentence  of  the  first  paragraph  to: 
"No  more  than  two  Network-specific  facilities 
information  elements  may  be  included  in  a  single 

message." 

Change  the  second  paragraph  to:  "The  maximum 
length  of  this  information  element  is  32  octets." 

Add  Attachment  D  of  this  document  to  the  end  of  this 
section. 

Delete  this  section. 


Secfion  4.5.21 
Progress  indicator 

Progress  description  (octet  4)  coding 

Section  4.5.21 
Progress  indicator 


Delete  row  "000  0100 
ISDN." 


4  call  has  returned  to  the 


Add  the  following  Note  after  Notes  1  and  2  following 
the  "Progress  description  (octet  4)"  coding:  "3  In 
the  SETUP  message,  in  the  user  to  network  direction 
(u  ->  n)  on  PRI,  one  of  two  values  may  be  used  in 
the  progress  description  tield:  'call  is  not  end-to-end 
ISDN'  (1),  or  'calling  equipment  is  non-ISDN'  (3). 
In  the  SETUP  message,  in  the  network  to  user 
direction  (n  ->  u)  on  PRI,  one  of  two  values  may  be 
used  in  the  progress  description  field:  'call  is  not 
end-to-end  ISDN'  (1),  or  'calling  equipment  is  non- 
ISDN'  (3)." 


Section  4.5.22 
Repeat  Indicator 

Section  4.5.24 
Signal 

Section  4.5.25 

Transit  network  selection 


Delete  this  section. 


Delete  this  section. 


Change  the  first  paragraph  to:  "The  purpose  of  the 
Transit  network  selection  information  element  is  to 
identify  one  requested  transit  network  (See  Annex 
C)." 
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Section  4.5.25 

Transit  network  selection 


Section  4.5.25 

Transit  network  selection 

Type  of  network  identification  (octet  3)  coding 

Section  4.5.25 

Transit  network  selection 

Network  identification  plan  (octet  3)  coding 

Section  4.5.26 
User-user 


Section  4.5.26 
User-user 

Protocol  discriminator  (octet  3)  coding 
Section  5 

Circuit-switched  call  control  procedures 


Section  5 

Circuit-switched  call  control  procedures 
Section  5.1 

Call  establishment  at  the  originating  interface 

Section  5.1.1 
Call  request 


Section  5.1.1 
Call  request 


Section  5.1.1 
Call  request 

Section  5.1.1 
Call  request 


Change  the  second  paragraph  to:  "The  default 
maximum  length  of  this  information  element  is  7 
octets." 

Delete  the  last  row  ("Oil  ..."). 


Delete  the  last  row  ("0011  ..."). 


Add  the  following  to  the  end  of  the  first  paragraph: 
"This  IE  is  to  be  included  based  on  the  User-to-user 
supplementary  service  description  and  user 
application." 

Change  "ANSI  T1.607"  to  "NIU  90-302"  in  the  last 
row  of  the  coding. 

Change  the  third  paragraph  ("All  messages  ...")  to: 
"All  messages  in  this  standard  contain  the  functional 
type  of  information  elements.  Functional  information 
elements  are  characterized  as  requiring  a  degree  of 
intelligent  processing  by  the  Customer  Premise 
Equipment  (CPE)  in  either  their  generation  or 
analysis." 

Delete  the  fifth  paragraph  ("As  a  general  ..."),  the 
second  Note  of  the  section,  and  the  seventh 
paragraphs  ("In  addition  ..."). 

Change  "ANSI  T1.602"  to  "NIU  89-210"  in  the  last 
sentence. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"The  Bearer  capability   information   element  is 
mandatory  in  the  SETUP  message." 

Change  the  third  paragraph  to:  "Furthermore,  the 
SETUP  message  shall  also  contain  all  of  the  call 
information  (i.e.,  address  and  facility  requests) 
necessary  for  call  establishment." 

Delete  the  following  from  the  fourth  paragraph:  "b) 
the  Keypad  information  ...  other  call  information," 
and  the  Note  ("All  networks  are  ..."). 

Delete  the  last  paragraph  ("For  overlap  ..."). 
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Section  5.1.2 

B -channel  selection  —  originating 


Delete  the  following  from  the  first  paragraph:  "c)  any 
channel  ...  alternative  c)  is  assumed." 


Section  5.1.2 

B -channel  selection 

Section  5.1.2 

B -channel  selection 


originating 


ongmating 


Section  5.1.2 

B -channel  selection  —  originating 


Section  5.1.2 

B -channel  selection 


originating 


Delete  the  last  sentence  from  the  third  paragraph: 
case  c),  the  ...  with  the  D-channel." 


"In 


Change  the  end  of  the  first  sentence  in  the  fourth 
paragraph  from  "(i.e.,  a  SETUP  ACKNOWLEDGE  or 
CALL  PROCEEDING  message)."  to  "(i.e.,  a  CALL 
PROCEEDING  message)." 

Change  the  fifth  paragraph  to:  "The  user  need  not 
attach  until  receiving  a:  a)  CALL  PROCEEDING,  b) 
ALERTING  message  with  the  progress  indicator  8 
'in-band  information  or  appropriate  pattern  is  now 
available'  or  c)  a  PROGRESS  message  with  the 
progress  indicator  1  'call  is  not  end-to-end  ISDN; 
further  call  progress  information  may  be  available  in- 
band'.  Prior  to  this  time,  the  network  cannot  assume 
that  the  user  has  attached  ...  (if  it  has  not  already 
done  so)." 

Change  the  first  sentence  of  the  last  paragraph  to: 
"In  case  a),  if  the  specified  channel  is  not  available, 
and  in  case  b)  if  not  channel  is  available,  a 
RELEASE  COMPLETE  message  with  a  cause  value 
of  44  'requested  circuit/channel  not  available'  or  34 
'no  circuit/channel  available',  respectively,  is  sent  by 
the  network  as  described  in  5.3." 


Section  5.1.3 
Overlap  sending 


Delete  this  section. 


Section  5.1.4 

Invalid  call  information 


Change  the  first  sentence  in  the  first  paragraph  to: 
"If,  following  the  receipt  of  the  SETUP  message,  the 
network  determines  ...  cause  such  as  the  following:". 


Section  5.1.4 

Invalid  call  information 


Add  the  following  to  the  end  of  the  first  paragraph 
after  "28  ...":  "82  'identified  channel  does  not  exist'." 


Section  5.1.5.1 

Call  proceeding,  en-bloc  sending 


Add  the  following  to  the  second  paragraph  after  "58 
...":  "34  'no  circuit/channel  available'." 


Section  5.1.5.2 

Call  proceeding,  overlap  sending 
Section  5.1.6 

Nofification  of  interworking  at  the  originating 
interface 


Delete  this  section. 


Change  "a)  ..."  in  the  first  paragraph  to:  "a)  in  an 
appropriate  call  control  message  when  a  state  change 
is  required  (CONNECT);  or,". 
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Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.6 

Notification  of  interworking  at  the  originating 
interface 

Section  5.1.7 

Call  confirmation  indication 


Section  5.2 

Call  establishment  at  the  destination  interface 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 


Section  5.2.1 
Incoming  call 

Section  5.2.1 
Incoming  call 


Add  to  the  end  of  "1  ..."  in  the  second  paragraph 
"(i.e.,  in  a  PROGRESS  message);  or,". 


Change  "2  ..."  in  the  second  paragraph  to:  "2 
'destination  address  is  non-ISDN'  (i.e.,  in  a 
CONNECT  message);". 

Delete  "4  ...  end-to-end  ISDN"  from  the  second 
paragraph. 

Delete  "or  more"  from  the  second  part  of  the  first 
sentence  in  the  fourth  paragraph. 

Change  the  last  sentence  in  the  first  paragraph  to: 
"When  the  user  receives  the  ALERTING  message,  the 
user  shall  enter  the  Call  Delivered  state." 

Delete  the  last  sentence  of  the  third  paragraph  ("No 
use  ..."). 

Delete  the  last  two  sentences  of  the  first  paragraph. 


Change  the  last  part  of  the  second  paragraph  from 
"(e.g.,  Display,  Low  layer  compatibihty)."  to  "(e.g.. 
Low  layer  compatibility.)". 

Add  the  following  to  the  end  of  the  second  paragraph: 
"In  general,  a  call  terminating  from  a  non-ISDN  line 
or  from  a  Public  Switched  Telephone  Network 
(PSTN)  trunk  should  be  offered  to  the  called  user 
equipment  with  the  3.1  kHz  audio  bearer  capability." 

Delete  the  first  and  second  sentences  of  the  third 
paragraph.  Delete  "However,  if ...  the  interface"  from 
tiie  third  sentence.  The  third  paragraph  will  now 
read:  "A  point-to-point  data  link  shall  be  used  to 
carry  the  SETUP  message.  After  sending  the  SETUP 
message,  the  network  starts  timer  T303." 

Delete  the  fifth  paragraph  and  the  Note  following  this 
paragraph. 

Change  the  second  part  of  the  last  sentence  in  the 
seventh  paragraph  from  "timers  T303  and  T312  are 
restarted."  to  "timer  303  is  restarted." 
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Section  5.2.2 
Compatibility  checking 

Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 
Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 


Section  5.2.3.1 

SETUP  message  delivered  by  point-to-point  data  link 


Section  5.2.3.2 

SETUP  message  delivered  by  broadcast  data  link 

Section  5.2.5.1 

Response  to  en-bloc  SETUP 


Section  5.2.5.1 

Response  to  en-bloc  SETUP 

Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 
Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Delete  the  second  paragraph  ("When  the  SETUP 
message  ..."). 

Delete  the  following  from  the  first  paragraph  under 
"a)        "3)  any  channel  is  acceptable." 

Delete  the  paragraph  under  "b) ...."  that  reads  "In  case 
3),  ...." 

Change  the  first  sentence  in  the  third  paragraph  under 
"b)"  to:  "If  in  case  1)  the  B-channel  indicated  in  the 
first  response  message  is  not  the  channel  offered  by 
the  network,  or  in  case  2)  the  B-channel  indicated  in 
the  first  response  message  is  unacceptable  to  the 
network,  it  will  clear  the  call  by  sending  a  RELEASE 
message  with  cause  6  'channel  unacceptable'  (see 
5.3.2  d)." 

Change  the  first  part  of  "e)  ..."  to:  "e)  In  case  1)  if 
the  indicated  B-channel  is  not  available,  or  in  case  2) 
if  no  B-channel  is  available 

Delete  this  section. 


Change  the  first  sentence  of  the  Note  to:  "A  Progress 
indicator  information  element  may  be  included  in  a 
CONNECT  message  (e.g.,  when  an  analogue  terminal 
is  connected  to  an  NT2  functional  grouping)." 

Delete  the  second  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  broadcast  ..."). 

Delete  the  first  paragraph  ("When  the  SETUP 
message  is  delivered  on  a  broadcast  ..."). 

Change  the  second  paragraph  to:  "Upon  receipt  of 
the  first  CALL  PROCEEDING  message  from  a  user, 
the  network  shall:  stop  timer  T303;  start  time  T310; 
and  enter  the  incoming  Call  Proceeding  state." 

Delete  the  fourth  paragraph  ("When  the  SETUP 
message  was  delivered  via  a  broadcast  ..."). 
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Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 


Section  5.2.5.2 

Receipt  of  CALL  PROCEEDING  and  ALERTING 
Section  5.2.5.3 

Called  user  clearing  during  Incoming  call 
establishment 

Section  5.2.5.3 

Called  user  clearing  during  Incoming  call 
establishment 

Section  5.2.5.3.1 

DISCONNECT  received  prior  to  expiry  of  T312 
Section  5.2.5.3.2 

DISCONNECT  received  after  expiry  of  Umer  T312 

Section  5.2.5.4 
Call  failure 

Section  5.2.5.4 
Call  failure 


Section  5.2.5.4 
Call  failure 

Section  5.2.5.4 
Call  failure 

Section  5.2.5.4 
Call  failure 


Section  5.2.5.4 
Call  failure 


Section  5.2.5.4 
Call  failure 


Change  the  fifth  paragraph  to:  "Upon  receipt  of  the 
ALERTING  message  from  a  user,  the  netvk'ork  shall: 
stop  Umers  T303  or  T310  (if  running)  and  TDEL  (if 
running);  start  optional  timer  T301  (unless  another 
internal  alerting  supervision  timer  function  exists;  w.g. 
incorporated  in  call  control);  enter  the  Call  Received 
state;  and  send  a  corresponding  ALERTING  message 
to  the  calling  user." 

Delete  the  sixth  paragraph  ("When  a  SETUP  message 
has  been  delivered  on  a  broadcast  link  ..."). 

Change  the  first  part  of  the  first  paragraph  to:  "If  the 
RELEASE  COMPLETE  or  DISCONNECT  message 
is  received 

Delete  the  second  and  third  paragraphs. 


Delete  this  section. 


Delete  this  section. 


Delete  the  following  from  the  first  paragraph:  "a)  If 
the  SETUP  message  ...  Call  Abort  state;" 

Change  "b)"  in  the  first  paragraph  to:  "b)  The 
network  shall  also  initiate  clearing  procedures  toward 
the  called  user  in  accordance  with  5.3.4,  using  cause 
102  'recovery  on  timer  expiry'." 

Delete  the  second  paragraph  ("If  the  network  receives 
..."). 

Delete  the  following  from  the  third  paragraph:  "a)  If 
the  SETUP  ...  shall  be  sent." 

Change  "b)"  in  the  third  paragraph  to:  "b)  The  called 
user  shall  be  cleared  in  accordance  with  5.3.4,  using 
cause  102  'recovery  on  timer  expiry'." 

Change  the  beginning  of  the  first  sentence  in  the 
fourth  paragraph  to:  "If  the  network  supports  timer 
T301  and  has  received  a  ALERTING  message  " 

Delete  from  the  fourth  paragraph:  "a)  If  the  SETUP 
message  was  ...  shall  be  sent." 
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Section  5.2.5.4 
Call  failure 


Section  5.2.6 

Notification  of  interworking  at  the  terminating 
interface 


Section  5.2.6 

Notification  of  interworking  at  the  termination 
interface 

Section  5.2.7 
Call  accept 


Section  5.2.8 
Active  indication 

Section  5.2.9 

Non-selected  user  clearing 

Section  5.3.2 
Exception  conditions 


Section  5.3.2 
Exception  conditions 

Section  5.3.2 
Exception  conditions 

Section  5.4 

In-band  tones  and  announcements 


Change  "b)"  in  the  fourth  paragraph  to:  "b)  The 
called  user  shall  be  cleared  in  accordance  with  5.3.4, 
using  cause  102  'recovery  on  timer  expiry'." 

Change  the  first  item  in  the  list  in  the  second 
paragraph  from:  " —  in  an  appropriate  ..."  to:  " —  in 
an  appropriate  call  conU"ol  message  when  a  state 
change  is  required  (CONNECT);  or,". 

Delete  the  third  item  from  the  list  in  the  third 
paragraph:  "4    Call  has 


Add  the  following  to  the  end  of  the  last  paragraph: 
"If  the  CONNECT  message  is  the  first  response  to  the 
SETUP  message,  it  shall  contain  the  channel 
identification  information  element." 

Delete  the  fourth  paragraph  ("A  user  that  has  received 
the  SETUP  via  the  broadcast  data  link  ..."). 

Delete  this  section. 


Change  in  the  first  paragraph  "a)"  to:  "a)  In  response 
to  a  SETUP  message,  the  user  or  network  can  reject 
a  call  (e.g.,  because  of  the  unavailability  of  a  suitable 
B-channel)  by:  responding  with  a  RELEASE 
COMPLETE  message  provided  no  other  response  has 
previously  been  sent  releasing;  the  call  reference  and 
entering  the  Null  state." 

Delete  from  the  first  paragraph:  "b)  In  the  case  ... 
user  clearing". 

Delete  from  the  first  paragraph  e)l)  and  e)2)  and  the 
Note  at  the  end  of  the  section. 

Change  the  title  of  this  section  to  "In-band  audible 
ringing  tone  and  announcements". 
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Section  5.4 

In-band  tones  and  announcements 


Change  the  tlrst  paragraph  to:  "It  is  assumed  that  the 
originating  Class  II  device  will  provide  a  busy  tone 
and  a  reorder  tone  to  the  calling  user  for  speech  and 
3.1  kHz  calls.  The  network  will  not  provide  in-band 
busy  or  reorder  tone.  When  in-band  audible  ringing 
tone/announcements  not  associated  with  a  call  state 
change  are  to  be  provided  by  the  network  before 
reaching  the  Active  state,  a  PROGRESS  message  is 
returned  simultaneously  with  the  application  of  the  in- 
band  audible  ringing  tone/announcement.  The 
PROGRESS  message  contains  the  progress  indicator 
8  'in-band  information  or  appropriate  pattern  is  now 
available'." 


Section  5.4  Change  the  second  paragraph  to:  "When  an  audible 

in-band  tones  and  announcements  ringing  tone  has  to  be  provided  together  with  a  ...  is 

sent  simultaneously  with  the  application  of  the  inband 

audible  ringing  tone." 

Section  5.4  Delete  Note  1. 

in-band  tones  and  announcements 


Section  5.4 

in-band  tones  and  announcements 


Change  Note  2  to:  "When  the  PROGRESS  message 
is  used,  the  user  may  initiate  call  clearing  as  a  result 
of  the  applied  in-band  audible  ringing  tone/ 
announcement,  according  to  procedures  specified  in 
5.3.3." 


Section  5.5 
Restart  procedure 


Delete  from  the  second  paragraph  "b)  the  interface  is 
a  ...  exists;  or,". 


Section  5.5.2 
Receipt  of  RESTART 


Change  in  Note  2  the  reference  to  "ANSI  T1.602"  to 
"NIU  89-210". 


Section  5.5.2 
Receipt  of  RESTART 


Change  in  Note  2  "b)"  to:  "b)  that  correspond  to  the 
specified  channel  or  interface." 


Section  5.7 
Call  collisions 


Delete  the  Note  at  the  end  of  the  section. 


Section  5.8.2 
Message  too  short 


Section  5.8.4 

Message  type  or  message  sequence  errors 
Section  5.8.7.2 

Non-mandatory  information  element  content  error 


Change  this  paragraph  to:  "When  a  message  is 
received  that  is  too  short  (less  than  4  octets)  to 
contain  a  complete  message  type  information  element, 
that  message  shall  be  ignored." 

Add  the  following  after  the  first  paragraph:  "The 
NOTIFY  message  may  be  ignored  by  the  recipient." 

Delete  the  last  sentence  of  the  second  paragraph 
("However,  in  some  ..."). 
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Section  5.8.8 
Data  link  reset 

Section  5.8.9 
Data  link  failure 

Section  5.8.9 
Data  link  failure 

Section  5.9 

User  notification  procedure 
Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Tuners  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.1 

Timers  in  the  network  side 

Table  22  —  Timers  in  the  network  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side 

Section  9.2 

Timers  in  the  user  side 

Table  23  —  Timers  in  the  user  side  (Part  2) 

Annex  A  —  SDL  diagrams 


Delete  from  the  first  paragraph:  "a)  For  calls  in  the 
Overlap  ...  procedures  of  5.3". 

Delete  from  the  first  paragraph  the  first  sentence  of 
"a)  ..."  ("The  calls  in  the  ...  internally."). 

Delete  the  second  sentence  of  the  Note  following  the 
first  paragraph  ("Note  —  If  tbe  transfer  mode  ...."). 

Delete  this  section. 


Delete  row  "T302". 


Delete  the  second  sentence  in  the  "T310/NORMAL 
STOP"  cell  ("If  DISCONNECT  ..."). 


Delete  rows  "T312"  and  "T321". 


Delete  Notes  4  and  5. 


Add  the  following  to  the  end  of  Note  6:  "(see  Annex 
D)". 


Delete  the  following  rows: 

•  "T301"; 

•  "T304". 

Delete  "SETUP  ACKNOWLEDGE"  from  the  "T303/ 
NORMAL  STOP"  cell. 


Delete  the  reference  to  "Note  4"  in  the  "T310AriMER 
NUMBER"  cell. 


Delete  Notes  3  and  4. 


Delete  this  section.  NOTE:  This  section  has  not 
been  addressed. 
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Section  B.3.1 

Compatibility  checking  with  addressing  information 

Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibiUty 
checking;  compatibiUty  assured 

Section  B.3.4 
User  action  figures 

Figure  B.l  —  Bearer  capability  compatibility 
checking 

Figure  B.2  —  Low  layer  and  high  layer  compatibility 
checking;  compatibiUty  assured 

Section  B.3.4 
User  action  figures 

Figure  B.3  —  Low  layer  and  high  layer  compatibility 
checking;  compatibiUty  not  assured 

Section  B.3.4 
User  action  figures 

Annex  C,  Section  C.l 
Introduction 

Annex  C,  Section  C.2 
Selection  Not  Supported 

Annex  C,  Section  C.3 
Selection  Supported 


Annex  C,  Section  C.3 
Selection  Supported 

Annex  C,  Section  C.3 
Selection  Supported 

Annex  C,  Section  C.3 
Selection  Supported 

Annex  D 

Extensions  for  Symmetric  Call  Operation 


Delete  Note  2  ("If  an  incoming  call,  ...  or 
subaddress."). 

Delete  the  reference  to  "(Note  1)"  from  the  cell  in  the 
first  row  of  the  second  column. 


Delete  the  "broadcast  data  link"  column. 


Delete  the  reference  for  "(Note  1)"  in  the  cells  in  the 
first  row  of  the  second  and  third  columns. 


Delete  Notes  1  and  3  (ed.  note:  Note  3  is  still 
referenced  in  the  figures). 

Delete  "optional"  from  the  first  paragraph. 
Delete  this  section. 


Change  the  first  paragraph  to:  "The  user  identifies 
the  selected  transit  network  in  the  SETUP  message. 
One  Transit  network  selection  informauon  element  is 
used  to  convey  a  single  network  idenufication." 

Delete  the  second  ("The  user  may  ..."),  third  ("As  the 
call  ..."),  and  fourth  ("No  more  than  ...")  paragraphs. 

Delete  the  last  sentence  of  the  sixth  paragraph  ("The 
diagnosuc  ..."). 

Delete  the  seventh  ("A  network  may  ...")  and  eighth 
("If  the  transit  ...")  paragraphs. 

Delete  Annex  D  and  replace  with  Attachment  E  of 
this  document. 
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Annex  E,  Section  E.3 
Routing  Not  Supported 


Add  the  following  paragraph  before  at  the  end  of  this 
section:  "When  the  requested  facility  can  not  be 
provided  an  indication  shall  be  returned  in  the  first 
clearing  message  with  cause  29  'facility  rejected'." 


Annex  E,  Section  E.4 
Routing  Supported 


Annex  E,  Section  E.4 
Routing  Supported 

Annex  F 

D-channel  Backup  Procedure 


Change  the  first  sentence  in  the  fourth  paragraph  to: 
"No  more  than  two  Network-specific  facilities 
information  elements  may  be  used  in  a  SETUP 
message." 

Delete  the  last  sentence  of  the  fifth  paragraph  ("The 
diagnostic  ..."). 

Delete  this  Annex. 


Annex  G,  Section  G.l 
Introduction 


Add  the  following  to  the  end  of  the  first  paragraph: 
"Section  4.5. 11  identifies  the  causes  supported  in  NIU 
90-302." 


Annex  G,  Section  G.3.8 

Cause  46  "precedence  call  blocked" 


Change  "precedence  circuits"  to  "preemptable 
circuits". 


Annex  H,  Section  H.l 
Introduction 


Change  the  first  paragraph  to:  "These  are  the  only 
recognized  codings  of  the  following  information 
elements." 


Annex  H,  Section  H.l 
Introduction 

Annex  H 

Examples  of  Information  Elements  Coding 


Delete  the  last  two  bullet  items  from  the  second 
paragraph. 

Delete  the  following  figures  and  sections: 

•  Figure  "H.3  Coding  for  7kHz  Audio"; 

•  Figure  "H.6  Coding  for  synchronous  1472  kbit/s"; 

•  Section  H.3  Channel  identification  information 
element; 

•  Section  H.4  Called  and  Calling  party  subaddress 
information  element. 


Annex  I 

Use  of  Progress  indicators 
Annex  I 

Use  of  Progress  indicators 
Annex  I 

Use  of  Piogress  indicators 
Annex  M 

Low  Layer  Compatibility  Negotiation 


Delete  the  fifth  paragraph  ("Progress  indicator  4  ..."). 


Delete  "or  basic"  from  the  left  side  of  Figure  1.1 
(between  the  TE  and  ISDN). 

Delete  "or  basic"  from  the  right  side  of  Figure  I.l 
(between  ISDN  and  NT2). 

Delete  this  Annex. 
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Annex  N 

Procedures  for  Establishment  of  Bearer  Connection 
Prior  to  Call  Acceptance 

Annex  O 

Optional  Procedures  for  Bearer  Service  Change 

Annex  P,  Section  P.l 
Introduction 

Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.l 
Introduction 


Annex  P,  Section  P.2 

Operator  system  access  requested  in  Keypad  facility 
information 

Section  P.4 
invalid  request 

Annex  Q 

Responding  address  requirements  of  the  OSI  network 
layer  service 


Delete  this  Annex  and  replace  with  Attachment  F  of 
this  document. 


Delete  this  Annex. 


Delete  "optional"  from  the  first  sentence  in  the  first 
paragraph. 

Change  the  last  sentence  of  the  first  paragraph  to: 
"These  procedures  apply  to  the  speech,  and  3.1  kHz 
and  audio  bearer  services." 

Change  the  second  paragraph  to:  "The  user  may 
indicate  a  request  for  access  to  an  operator  or 
attendant  system  using  the  Operator  system  access 
information  element." 

Delete  this  section. 


Delete  this  section. 


Delete  this  Annex. 
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Attachment  A 

(of  Appendix  B) 

1.  General 

1.1  Scope  and  Purpose 

This  Implementation  Agreement  specifies  a  minimal  subset  of  procedures  and  codepoints  from  the  American  National 
Standards  Tl  .607- 1990  (Ref.  [17])  for  the  establishment,  maintenance,  and  clearing  of  ISDN  connections  at  the  user- 
to-network  interface.  This  signalling  standard  is  used  to  support  the  circuit-switched  bearer  services  specified  in  ANS 
Tl. 604- 1990*. 

Terminals  are  not  required  to  support  all  services.  Switches  will  support  all  of  the  mandatory  protocols  and 
codepoints  in  this  implementation  agreement.  This  does  not  preclude  the  support  of  additional  services  and 
procedures.  However,  equipment  must  be  able  to  interoperate  with  equipment  supporting  only  this  minimal  subset. 

1.1.1  Definitions 

The  ANS  Tl.607-1990  (Ref.  [17])  assumes  that  procedures  apply  generically  to  ISDN  access  interfaces,  i.e.,  the 
document  does  not  distinguish  between  basic  and  primary  rates  access  interfaces.  In  addition,  there  are  no  references 
to  specific  applications  in  that  document.  The  concept  of  equipment  classes  is  introduced  in  this  document  to  permit 
certain  procedures  to  be  associated  with  a  particular  application  or  class  of  equipment,  e.g.,  station  equipment  versus 
PBX.  Specifically,  two  classes  of  equipment  are  defined  on  the  basis  of  two  fundamental  attributes. 

The  first  attribute  relates  to  the  possibility  of  an  exchange  of  signals  occurring  beyond  the  public  network's  point 
of  contact  with  the  interface  (i.e.,  between  the  equipment  directly  connected  to  the  public  network  and  ISDN 
terminals  or  telephones  connected  to  that  equipment).  For  example,  some  user  equipment  may  support  subtending 
Basic  Access  digital  subscriber  loops  and/or  analog  telephone  loops.  For  Class  1  equipment,  the  network  makes  no 
provision  for  such  an  arrangement  and  assumes  the  Class  I  equipment  constitutes  the  endpoint  of  the  communication. 
Conversely,  in  the  case  of  Class  II  equipment,  the  procedures  at  the  network  take  into  account  that  conmiunication 
between  Class  II  equipment  (with  which  it  conmiunicates  directly)  and  other  equipment  (with  which  the  network  does 
not  have  direct  contact)  may  occur.  As  an  example,  Class  II  equipment  may  support  digital  and/or  analog  subscriber 
loops.  Use  of  Class  II  equipment  also  involves  the  possibility  of  having  interworking  occur  beyond  the  equipment 
with  which  the  network  has  direct  contact.  Therefore,  it  is  reasonable  for  Class  II  equipment  to  provide  the  network 
with  an  interworking  notification,  for  both  outgoing  and  incoming  calls,  when  either  the  calling  or  called  party 
respectively,  is  a  non-ISDN  user.  Class  II  equipment  may  also  send  an  interworking  notification  if  a  private  network 
exists  beyond  the  Class  II  equipment  and  interworking  to  a  non-ISDN  facility  within  that  network  takes  place.  When 
an  interface  is  associated  with  Class  I  equipment,  it  is  assumed  the  multiple  pieces  of  equipment  may  exist  and 
communicate  with  the  network  over  the  D-channel.  However,  in  this  case,  all  equipment  is  assumed  to  be  ISDN- 
capable  and  is  considered  as  the  endpoint  of  the  communication.  Therefore,  interworking  notification  should  not  be 
accepted  from  Class  I  equipment. 

The  second  attribute  relates  to  the  manner  in  which  a  SETUP  message  should  be  presented  to  the  user  equipment. 
When  Class  I  equipment  is  applied  on  a  particular  interfaces,  the  network  should  broadcast  the  SETUP  message 
associated  with  each  call  that  terminates  on  that  interface,  since  interaction  between  the  network  and  multiple  pieces 
of  user  equipment  should  be  supported.  On  the  other  hand,  the  network  should  not  broadcast  SETUP  messages 
associated  with  terminating  calls  to  an  interface  on  which  Class  II  equipment  is  being  used.  Here,  a  single  piece 
of  user  equipment  is  assumed  to  be  involved  in  all  conununication  with  the  network. 


'Subject  to  further  discussion. 
NIU-Forum  Agreements  On  ISDN 


B-33 


To  the  extent  possible,  it  is  desirable  to  have  one  set  of  requirements  for  ISDN  call  control  apply  to  all  ISDN  user 
configurations.  However,  in  cases  for  which  integrated  procedures  are  not  appropriate,  the  call  control  procedures 
associated  with  Equipment  Class  I  will  differ  from  those  associated  with  Equipment  Class  II.  Unless  otherwise 
noted,  the  assumption  should  be  that  a  particular  procedure/capability  should  be  provided  for  both  classes  of 
equipment  on  both  basic  and  primary  rate  access.  However,  use  of  the  equipment  class  terminology  permits 
clarification  of  the  circumstances  under  which  a  certain  capability  should  be  available  (i.e.,  when  a  particular 
equipment  class  is  in  use).  It  also  permits  a  mechanism  for  indicating  that  a  particular  capability  applies  only  to  a 
subset  of  four  possible  configurations  which  are  labeled  as  follows. 


Class  I  Class  II 


IB 

IIB 

IP 

IIP 

In  other  words,  a  capability  that  applies  to  Class  I  equipment  may  be  provided  on  basic  access  interfaces  (IB)  and/or 
primary  rate  access  interfaces  (IP).  Similarly,  a  capability  that  applies  to  Class  II  equipment  may  be  provided  on 
basic  access  interfaces  (IIB)  and/or  primary  rate  access  interfaces  (IIP). 

The  notation  shown  in  the  table  above  is  used  within  this  implementation  agreement  to  indicate  when  protocol  or 
procedures  are  only  expected  to  be  supported  for  a  particular  equipment  class  and/or  are  limited  to  a  particular  type 
of  interface,  i.e.,  basic  or  primary  rate  interface. 
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(of  Appendix  B) 

The  various  parts  of  the  called  party  number  information  element  should  be  coded  as  follows: 

—  Type  of  number  and  numbering  plan  (octet  3) 
Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1      International  number  in  ISDN  numbering  plan  (Rec.  E.164) 

0  1  0  0  0  0  1      National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1     Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 

All  other  values  are  reserved 


—  Digits  (octet  4,  etc.) 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

000 

0 

0 

0 

1 

1 

0  0  0 

1 

1 

0 

1 

1 

0  0  1 

0 

2 

0 

1 

1 

0  0  1 

1 

3 

0 

1 

1 

0  1  0 

0 

4 

0 

1 

1 

0  1  0 

1 

5 

0 

1 

1 

0  1  1 

0 

6 

0 

1 

1 

0  1  1 

1 

7 

0 

1 

1 

1  00 

0 

8 

0 

1 

1 

1  00 

1 

9 

All  other  values  are  reserved 

Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  above. 

In  the  network  to  user  direction  (n  ->  u),  this  IE  will  be  always  signaled  in  the  SETUP  message,  and  public  network 
interfaces  will  use  only  one  codepoint:  local  number  in  ISDN.  For  private  networks,  this  IE  can  contain  the 
following  codepoints:  abbreviated  type  of  number,  and  private  numbering  plan,  and  extra  digits  such  A,  B,  C,  and 
D  (as  per  IA5). 


NIU-Forum  Agreements  On  ISDN 


B-35 


Attachment  C 

(of  Appendix  B) 

The  various  parts  of  the  calling  party  number  information  element  should  be  coded  as  described  below. 

—  Type  of  number  and  numbering  plan  (octet  3)  follows: 
Bits 

7  6  5  4  3  2  1  Meaning  

0  0  0  0  0  0  0  Unknown 

0  0  1  0  0  0  1     International  number  in  ISDN  numbering  plan  (Rec.  E.164) 
0  0  1  0  0  1  1     International  number  in  data  numbering  plan  (Rec.  X.121) 

0  1  0  0  0  0  1     National  number  in  ISDN  numbering  plan  (Rec.  E.164) 

1  0  0  0  0  0  1     Local  (directory)  number  in  ISDN  numbering  plan  (Rec.  E.164) 

110  10  0  1     Abbreviated  Number  in  Private  Numbering  plan 

All  other  values  are  reserved 


Origin  of  number  and  presentation  status  (octet  3a)  follows: 
Bits 

7  6  5  4  3  2  1  Meaning 


0  0  0  0  0  0  0    Presentation  allowed  of  user-provided  number, 
number  not  screened 

0  0  0  0  0  0  1    Presentation  allowed  of  user-provided  number, 
number  passed  network  screening 

0  0  0  0  0  1  0    Presentation  allowed  of  user-provided  number, 
number  failed  network  screening 

0  0  0  0  0  1  1    Presentation  allowed  of  network-provided  number 

0  1  0  0  0  0  0    Presentation  prohibited  of  user-provided  number, 
number  not  screened 

0  1  0  0  0  0  1    Presentation  prohibited  of  user-provided  number, 
number  passed  network  screening 

0  1  0  0  0  1  0    Presentation  prohibited  of  user-provided  number, 
number  failed  network  screening 

0  1  0  0  0  1  1    Presentation  prohibited  of  network-provided  number 

1  0  0  0  0  1  1    Number  not  available 

All  other  values  are  reserved 


Note  1  —  When  octet  3a  is  omitted,  the  default  value  of  the  Number  Presentation  parameter  for  the  signaled  DN 
value  should  be  used,  if  it  is  available.  If  a  value  for  this  parameter  is  unavailable  (i.e.,  the  signaled  DN  value  either 
fails  screening  or  is  not  screened  by  the  SPCS),  the  presentation  parameter  value  of  the  default  DN  should  be  used. 

Note  2  —  Octet  3a,  bits  7  &  6,  are  for  the  Presentation  indicator;  bits  2  &  1  are  for  the  screening  indicator. 
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—  Digits  (octet  4,  etc.) 


Digits  should  be  represented  by  IA5  characters  whose  encoding  is  shown  below: 

Bits 

7  6  5  4  3  2  1  Meaning 


0 

1 

1 

0000 

0 

0 

1 

1 

0  0  0  1 

1 

0 

1 

1 

0  0  10 

2 

0 

1 

1 

00  11 

3 

0 

1 

1 

0  10  0 

4 

0 

1 

1 

0  10  1 

5 

0 

1 

1 

0  110 

6 

0 

1 

1 

0  111 

7 

0 

1 

1 

100  0 

8 

0 

1 

1 

100  1 

9 

All  other  values  reserved 


Codings  At  Originating  Party  Interface 

The  calling  party  number  information  element  should  only  be  accepted  when  in  the  SETUP  message.  When  the  type 
of  number  and  numbering  plan  indicator  indicates  "local  number  in  the  ISDN  (E.164)  numbering  plan,"  the  calling 
party  number  information  element  should  contain  a  7-digit  local  number.  When  the  type  of  number  and  numbering 
plan  indicator  indicates  "national  number  in  the  ISDN  (E.164)  numbering  plan"  the  calling  party  number  information 
element  should  contain  a  10-digit  national  number. 

In  the  network  to  user  direction  (n  ->  u).  the  coding  and  delivery  of  this  IE  depends  on  the  definition  of  the  Calling 
Line  ID  service.  For  private  networks,  this  IE  can  contain  the  following  codepoints:  abbreviated  type  of  number, 
and  private  numbering  plan,  and  extra  digits  such  as  A,  B,  C,  and  D.  (as  per  IE5) 
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Attachment  D 

(of  Appendix  B) 


Network  —  Specific  facilities  Information  Element  Examples 

One  recommended  use  for  the  Network  Specific  Facilities  information  element  is  to  indicate  which  type  of  network 
facilities  are  being  invoked  at  the  specified  network.  In  this  arrangement,  many  different  facility  types  are  allowed 
to  share  a  single  Primary  Rate  Interface.  Examples  of  the  different  DS-1  facility  types  allowed  are: 

Private  Lines 
Inwats  Circuits 
Outwats  Circuits 
Foreign  Exchange  (FX) 
Tie  Trunks 
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Attachment  E 

(of  Appendix  B) 

(editor's  note:  the  sections  contained  in  the  parentheses  are  unchanged  from  the  original  Annex  D) 
Annex  D  —  Extensions  for  symmetric  (peer-to-peer)  call  operation 
This  annex  is  part  of  NIU  90-302. 

Symmetric  call  operation,  or  peer-to-peer  call  operation,  shall  be  applied  to  the  switches  within  a  private  network 
where  all  switches,  such  as  PBXs  and  central  office  switches  serving  business  group  users  are  considered  as  peers. 
For  example,  PBX-to-PBX,  PBX-to-Centrex,  Centrex-to-Centrex. 

D.  1  Additional  message  handling 

(In  symmetric  applications,  the  SETUP  message  will  contain  a  Channel  Identification  information  element  indicating 
a  particular  B -channel  to  be  used  for  the  call.  A  point-to-point  data  hnk  shall  be  used  to  carry  the  SETUP  message.) 

The  following  procedures  shall  be  followed  for  symmetrical  operation.  The  call  control  states  followed  should  be 
the  symmetric  states  defined  in  section  D.6. 

D.1.1  Call  Request 

The  initiator  of  the  call  shall  follow  the  network  side  procedures  described  in  section  5.2.1. 
D.1.2  B-channel  Selection  —  symmetric  interface 

(Only  B -channels  controlled  by  the  same  D-channel  will  be  the  subject  of  the  selection  procedure.  The  selection 
procedure  is  as  follows: 

a)  The  SETUP  message  will  indicate  one  of  the  following: 

1)  channel  is  indicated,  no  acceptable  alternative,  or 

2)  channel  is  indicated,  any  alternative  is  acceptable. 

b)  In  cases  1)  and  2),  if  the  indicated  channel  is  acceptable  and  available,  the  recipient  of  the  SETUP 
message  reserves  it  for  the  call.  In  case  2),  if  the  recipient  of  the  SETUP  message  cannot  grant 
the  indicated  channel,  it  reserves  any  other  available  B-channel  associated  with  the  D-channel.) 

c)  The  recipient  of  the  SETUP  message  indicates  the  selected  B-channel  in  a  CALL  PROCEEDING, 
message  fransferred  across  the  interface  and  enters  the  Incoming  Call  Proceeding  state.  If  an 
ALERTING  or  a  CONNECT  message  is  received  in  response  to  a  SETUP  message,  the  call  should 
continue  to  be  processed,  if  the  channel  indicated  is  acceptable  to  the  initiator  of  the  call,  in 
accordance  with  sections  D. 1.5.1  and  D.1.8,  respectively.  Although  these  are  acceptable  responses, 
a  CALL  PROCEEDING  message  is  the  recommended  response  to  a  SETUP  message. 

d) 

e)  In  case  1)  if  the  indicated  B-channel  is  not  available,  or  in  case  2)  if  no  B-channel  is  available,  a 
RELEASE  COMPLETE  message  with  a  cause  value  of  No.  44  "requested  circuit/channel  not 
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available"  or  No.  34  "no  circuit/channel  available"  respectively  is  returned  to  the  initiator  of  the 
call.  The  sender  of  this  message  remains  in  the  Null  state. 

f)  If  the  channel  indicated  in  the  CALL  PROCEEDING,  message  is  unacceptable  to  the  initiator  of 
the  call,  it  clears  the  call  in  accordance  with  section  5.3.  If  an  ALERTING  or  a  CONNECT 
message  is  received  in  response  to  a  SETUP  message  and  the  channel  indicated  is  unacceptable 
to  the  initiator  of  the  call,  it  clears  the  call  in  accordance  with  section  5.3.  Although  these  are 
acceptable  responses,  a  CALL  PROCEEDING  message  is  the  reconmiended  response  to  a  SETUP 
message. 

D.1.3  Invalid  Call  Information 

The  recipient  of  a  SETUP  message  shall  follow  the  network  side  procedures  described  in  section  5.1.4. 
D.1.4  Compatibility  Checking 

The  recipient  of  a  SETUP  message  shall  follow  the  user  side  procedures  described  in  section  5.2.2. 
D.1.5  Call  Confirmation 

Upon  receipt  of  a  SETUP  message,  the  equipment  enters  the  Call  Present  state.  Valid  responses  to  the  SETUP 
message  are  a  CALL  PROCEEDING,  or  a  RELEASE  COMPLETE  message.  If  an  ALERTING  or  a  CONNECT 
message  is  received  in  response  to  a  SETUP  message,  the  call  should  continue  to  be  processed,  if  the  channel 
indicated  is  acceptable  to  the  initiator  of  the  call,  in  accordance  with  sections  D. 1.5.1.  and  D.1.8,  respectively. 
Although  these  are  acceptable  responses,  a  CALL  PROCEEDING  message  is  the  recommended  response  to  a  SETUP 
message. 

If  the  indicated  channel  is  acceptable  to  the  initiator  of  the  call,  the  initiator  shall  attach  to  the  indicated  B -channel 
according  to  the  procedures  in  Annex  N. 

D.L5.1  Receipt  of  CALL  PROCEEDING  and  ALERTING 

The  Initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.2. 

D.1.5. 2  Clearing  during  incoming  call  establishment 

The  initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.3. 
D.1.5.3  Call  Failure 

The  initiator  of  a  call  shall  follow  the  network  side  procedures  in  section  5.2.5.4. 
D.1.6  Clearing  by  the  called  user  employing  user-provided  tones/announcements 

When  tones  or  announcements  are  provided  in  conjunction  with  call  clearing,  the  party  providing  the  in-band 
treatment  shall  send  a  PROGRESS  message. 

D.1.7  Call  Accept 

The  recipient  of  the  call  shall  follow  the  user  side  procedures  in  section  5.2.7. 
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D.1.8  Active  indication 

Upon  receipt  of  a  CONNECT  message,  the  initiator  of  the  call  shall  respond  with  a  CONNECT  ACKNOWLEDGE 
message  and  enter  the  Active  State  (see  sec.  5.2.8  network  side  procedures). 

D.I.9  Call  Clearing 

D.  1.9.1  Normal  Call  Clearing 

Then  sender  of  the  DISCONNECT  message  shall  follow  the  user  side  procedures  in  section  5.3.3.  The  recipient  of 
the  DISCONNECT  message  shall  follow  the  network  side  procedures  in  section  5.3.3. 

D.2  Timers  for  call  establishment 

The  timers  described  in  section  9  table  7  shall  be  implemented  along  with  the  corresponding  procedures  for  action's 
taken  upon  expiration  of  these  timers.  The  default  of  T310  should  be  extended  to  20  seconds.  In  addition,  timer 
T309  shall  be  mandatory. 

D.3  Call  collisions 

In  synunetric  arrangements,  call  colUsions  can  occur  when  both  sides  simultaneously  transfer  a  SETUP  message 
indicating  the  same  channel.  In  the  absence  of  administrative  procedures  for  assignment  of  channels  to  each  side 
of  the  interface,  the  following  procedure  is  employed. 

First,  one  side  of  the  interface  will  be  designated  the  "controlling  function"  and  the  other  side  of  the  interface  will 
be  designated  the  "responding  function."  This  can  be  accomplished  by  administering  the  Layer  2  Command/ 
Response  bit.  The  controlling  function  is  assigned  "command"  and  has  control  of  all  the  channels  on  the  interface. 
The  responding  function  is  assigned  "response."  Second,  for  the  three  possible  scenarios  where  the  same  channel 
is  indicated  by  combinations  of  preferred  and  exclusive  from  the  responding  function  and  controlhng  function,  the 
following  procedure  is  used: 

a)  "controlling  function"  preferred,  "responding  function"  preferred: 

The  "controlling  function"  preferred  channel  is  awarded  and  an  alternate  channel  is  indicated  in 
the  first  response  to  the  "responding  function"  SETUP  message. 

b)  "controlling  function"  exclusive,  "responding  function"  exclusive: 

The  "controlling  function"  exclusive  channel  is  awarded  and  the  "responding  function"  SETUP 
message  is  cleared  with  a  RELEASE  COMPLETE  message  with  cause  No.  34  "no  circuit/channel 
available". 

c)  "controlling  function"  preferred,  "responding  function"  exclusive;  or  "controlling  function" 
exclusive,  "responding  function"  preferred: 

The  side  of  the  interface  with  an  exclusive  indicator  in  a  SETUP  message  is  awarded  the  channel 
and  an  alternate  channel  is  indicated  in  the  first  response  to  the  side  using  a  preferred  indicator  in 
the  SETUP  message. 

Channel  identification  is  allowed  in  both  directions  for  ALERTING  and  CONNECT. 
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DA       Restart  Procedures 
See  section  5.5. 

D.5       Handling  of  Error  Codes 
See  section  5.8. 

D.6       Call  control  states  for  symmetric  call  operation 

The  state  below  are  used  in  association  with  call  references  other  than  the  global  call  reference,  and  apply  to 
symmetric  interfaces.  The  Outgoing  side  is  the  side  of  the  symmetric  interface  that  transmits  the  SETUP  message, 
while  the  incoming  side  is  the  recipient  of  the  SETUP  message. 

D.6.1     Null  State  (SO) 

No  call  exists. 

D.6.2     Call  Initiated  (SI) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  sent  a  request  for  call  establishment  to  the 
Incoming  Side  but  has  not  yet  received  a  response. 

D.6. 3     Outgoing  Call  Proceeding  (S3) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  received  acknowledgment  that  the  Incoming  Side 
has  received  all  call  information  necessary  to  effect  call  establishment. 

D.6.4     Call  Delivered  (S4) 

This  state  exists  for  an  outgoing  call  when  the  Outgoing  Side  has  received  from  the  Incoming  Side  an  indication  that 
the  called  user  is  being  alerted. 

D.6.5     Call  Present  (S6) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  not  yet  responded  to  the  request  from  the 
Outgoing  Side  for  call  establishment. 

D.6.6     Call  Received  (S7) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  indicated  to  the  Outgoing  Side  that  the  called  user 
is  being  alerted. 

D.6. 7    Connect  Request  (S8) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  indicated  to  the  Outgoing  Side  that  the  called  user 
has  answered  the  call. 

D.6.8    Incoming  Call  Proceeding  (S9) 
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This  state  exists  for  an  incoming  call  when  the  Incoming  Site  has  sent  to  the  Outgoing  Side  acknowledgment  that 
it  has  received  all  call  information  necessary  to  effect  call  establishment. 

D.6.9    Active  (SIO) 

This  state  exists  for  an  incoming  call  when  the  Incoming  Side  has  received  from  the  Outgoing  Side  an 
acknowledgment  of  the  indication  that  the  called  user  has  answered  the  call.  This  state  exists  for  an  outgoing  call 
when  the  Outgoing  Side  has  received  from  the  Incoming  Side  an  indication  that  the  called  user  has  answered  the 
call. 

D.6.10  Disconnect  Request  (SI  1) 

This  state  exists  when  a  Side  has  sent  to  the  other  Side  a  request  to  disconnect  the  user  information  connection  and 
is  waiting  for  a  response. 

D.6.11  Disconnect  Indication  (SI 2) 

This  state  exists  when  a  Side  has  received  from  the  other  Side  a  request  to  disconnect  the  user  information 
connection  and  has  not  yet  responded. 

D.6.12  Release  Request  (S19) 

This  state  exists  when  a  Side  has  sent  to  the  other  Side  a  request  to  release  the  call  and  has  not  yet  received  a 
response. 
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Attachment  F 

(of  Appendix  B) 

Annex  N  —  Procedures  for  Establishment  of  Bearer  Connection  Prior  to  Call  Acceptance 
This  annex  is  part  of  NIU  90-302. 
N.l  General 

For  some  applications,  it  is  desirable  to  allow  the  completion  of  the  transmission  path  associated  with  a  bearer  service 
prior  to  receiving  call  acceptance.  In  particular,  the  completion  of  the  backward  direction  for  non-peer 
communication  or  both  directions  for  peer-to-peer  communication  (see  Annex  D  for  peer-to-peer  call  operation)  of 
the  transmission  path  prior  to  receipt  of  a  CONNECT  message  from  the  called  user  may  be  desirable  to: 

1)  allow  the  called  user  to  provide  internally-generated  tones  and  announcements  that  are  sent  in-band 
to  the  calling  user  prior  to  answer  by  the  called  user;  or, 

2)  avoid  speech  clipping  on  connections  involving  an  NT2  where  delays  may  occur  in  relaying  the 
answer  indication  within  the  called  user  equipment. 

The  procedures  described  in  this  annex  are  applicable  to  the  speech  and  3.1  kHz  audio  bearer  services,  for  non-peer 
communication  of  both  directions  for  peer-to-peer  communication  (see  Annex  D  for  peer-to-peer  call  operation). 

N.2  Procedures 

Completion  of  the  transmission  path  prior  to  receipt  of  a  call  acceptance  indication  shall  be  provided  in  three  ways: 

1)  For  peer-to-peer  communications  on  receipt  of  a  CALL  PROCEEDING  message  or  an  ALERTING 
message  indicating  completion  of  successful  channel  negotiation. 

2)  For  non-peer  communication  on  receipt  of  an  ALERTING  message;  and 

3)  For  non-peer  communications  on  receipt  of  a  PROGRESS  message. 

When  criteria  (1)  is  used  to  determine  that  a  U"ansmission  path  should  be  established,  the  sender  of  the  SETUP 
message  shall  connect,  both  directions  of  the  transmission  path  upon  receipt  of  either  a  CALL  PROCEEDING 
message  or  an  ALERTING  message  containing  an  acceptable  B -channel  indication. 

When  criteria  (2)  is  used  to  establish  the  transmission  path,  the  network  shall  connect,  the  backward  direction  of  the 
transmission  path  upon  receipt  of  an  ALERTING  message  assuming  channel  negotiation  procedures  have  been 
successful. 

When  criteria  (3)  is  used  to  establish  the  U"ansmission  path,  the  network  shall  connect,  the  backward  direction  of  the 
transmission  path  upon  receipt  of  a  PROGRESS  message  containing  progress  indicator  1  "call  is  not  end-to-end 
ISDN;  further  call  progress  information  may  be  available  in-band,"  assuming  that  the  user  has  already  returned  a 
CALL  PROCEEDING  message  and  channel  negotiation  procedures  have  been  successful. 

If  an  ALERTING  message  follows  a  PROGRESS  message  containing  progress  indicator  1,  it  should  be  treated  as 
an  unexpected  message. 
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The  network  may  choose  to  further  restrict  when  message(s)  will  result  in  establishment  of  the  transmission  path. 
These  restrictions  may  be  imposed  on  a  per  interface  basis  to  provide  an  administrative  means  for  limiting  potential 
misuse  of  the  early  connection  capabilities. 


NIU-Forum  Agreements  On  ISDN 


B-45 


4 


Acronyms 

3PTY  Three  Party  Service 

ACD  Automatic  Call  Distributor 

ACTl  Abstract  Conformance  Test  Group  for  Layer  1 

ACT23  Abstract  Conformance  Test  Group  for  Layers  2  and  3 

AE  ASI  Entity 

ALLF  Additional  Lower  Layer  Functions 

ANS  American  National  Standard 

ANSI  American  National  Standards  Institute 

AOC  Advice  of  Charge 

AOW  Asian  Oceanic  Workshop 

AP  Application  Profile 

ARS  Automatic  Route  Selection 

ACSE  Association  Control  Service  Element 

ASI  Application  Software  Interface 

BLLF  Basic  Lower  Layer  Functions 

HOC  Bell  Operating  Company 

BRA  Basic  Rate  Access 

BRI  Basic  Rate  Interface 

CCBS  Completion  of  calls  to  busy  subscribers 

CCITT  International  Telephone  and  Telegraph  Consultative  Committee 

CCR  Concurrency,  Conmiitment,  and  Recovery 

CD  Call  Deflection 

CFB  Call  Forward  Busy 

CFNR  Call  Forward  No  Reply 

CFU  Call  Forwarding  Unconditional 

CLID  Calling  Line  Identification 

CLIP  Calling  Line  Identification  Presentation 

CLIR  Calling  Line  Identification  Restriction 

CO  Central  Office 

COLP  Connected  Line  Identification  Presentation 

COLR  Connected  Line  Identification  Restriction 

CONF  Conference  calling 

COS  Corporation  for  Open  Systems 

CPE  Customer  Premises  Equipment 

CPN  Calling  Party  Number 

CRED  Credit  Card  Calling 

CSD  Circuit-Switched  Data 

CSV  Circuit-Switched  Voice 

CT  Conformance  Test 

CT  Call  Transfer 

CUG  Closed  User  Group 

CVN  Call  Forwarding  No  Answer 

CW  Call  Waiting 

DCE  Data  Circuit-Terminating  Equipment  7 
DN  Directory  Number 

DSSl  Digital  Subscriber  Signalling  System  Number  1 

DTE  Data  Terminal  Equipment 

DTP  Distributed  Transaction  Processing 

EAMF  Equal  Access  Multi-Frequency 
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ECMA  European  Computer  Manufacturers  Association 

EDI  Electronic  Data  Interchange 

ESCA  Exchange  Carriers  Standards  Association 

ETSI  European  Telecommunications  Standards  Institute 

EWOS  European  Workshop  for  Open  Systems 

FIPS  Federal  Information  Processing  Standard 

FT  AM  File  Transfer  and  Management 

FTP  File  Transfer  Protocol 

HLDC  High-Level  Data  Link  Control 

HLF  High  Level  Function 

HOLD  Call  Hold 

lA  Implementation  Agreements 

ICOT  ISDN  Conformance  Test 

ICS  Implementation  Conformance  Statement 

irw  ISDN  Implementors  Workshop 

INTAP  Interoperability  Technical  Association  Processing 

ISDN  Integrated  Services  Digital  Network 

ISER(M)  ISDN  Station  Event  Recording  (Module) 

ISP  International  Standardized  Profile 

ISPICS  International  Standardized  Profiles  Implementation  Conformance  Statement 

lUW  ISDN  Users  Workshop 

IWF  Interworking  Functions 

LAN  Local  Area  Network 

LAPD  Link  Access  Procedure,  D-Channel 

LLSIG  Lower  Layer  Special  Interest  Group 

MA  Messaging  and  Answering 

MCI  Malicious  Call  Identification 

MSN  Multiple  Subscriber  Number 

MWI  Message  Waiting  Indicator 

NA  Network  Adapter 

NFS  Network  File  System 

NIST  National  Institute  of  Standards  and  Technology 

NIUF  North  American  ISDN  Users  Forum 

NMWG  Network  Management  Expert  Working  Group 

NT  Network  Termination 

NUI  Network  User  Identification 

OIW  OSI  Implementors  Workshop 

OSI  Open  Systems  Interconnection 

pAP  proposed  Application  Profile 

PBX  Private  Branch  Exchange 

PNP  Private  Numbering  Plan 

PRA  Primary  Rate  Access 

PRI  Primary  Rate  Interface 

PSD  Packet-Switched  Data 

PSN  Private  Switched  Network 

REV  Reverse  Charging 

RL  Requirments  List 

RPN  Redirecting  Paity  Number 

SAP  Service  Acces  Point 

SCAI  Switch-Computer  Applications  Interface 

SNA  Systems  Network  Architecture 
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SPID  Station  Profile  Identification 

SPO  Standards  Promotion  Organization 

SS  Supplementary  Service 

SS7  Signalling  System  Number  7 

SUB  Sub-addressing 

SWG  Signalling  Working  Group 

TA  Terminal  Adapter 

TE  Terminal  Equipment 

TEI  Terminal  Endpoint  Identifier 

TEN  Transferred  From  Number 

TP  Transaction  Processing  (Distributed) 

TPN  Transferred  Party  Number 

TPSE  Transaction  FYocessing  Service  Element 

TTCN  Tree  and  Tabular  Combined  Notation 

TTN  Transferred  To  Number 

UUS  User-to-User  Signalling 

VMS  Voice  Messaging  Systems 

VPN  Virtual  Private  Network 

WAN  Wide  Area  Network 

WG  Working  Group 
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ANNOUNCEMENT  OF  NEW  PUBLICATIONS  ON 
INTEGRATED  SERVICES  DIGITAL  NETWORK 


Superintendent  of  Documents 
Government  Printing  Office 
Washington,  DC  20402 


Dear  Sir: 

Please  add  my  name  to  the  announcement  list  of  new  publications  to  be  issued  in 
the  series:  National  Institute  of  Standards  and  Technology  Special  Publication  823-. 

Name  

Company  ^  

Address  

City   State  Zip  Code   


(Notification  key  N-503) 


NIST 


Technical  Publications 

Periodical 

Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology- Reports  NIST 
research  and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in 
which  the  Institute  is  active.  These  include  physics,  chennistry,  engineering,  mathematics,  and 
computer  sciences.  Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on 
measurement  methodology  and  the  basic  technology  underlying  standardization.  Also  included 
from  time  to  time  are  sun/ey  articles  on  topics  closely  related  to  the  Institute's  technical  and 
scientific  programs.  Issued  six  times  a  year. 


Nonperiodicals 


Monographs— Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks- Recommended  codes  of  engineering  and  industrial  practice  (including  safety 
codes)  developed  in  cooperation  with  interested  industries,  professional  organizations,  and 
regulatory  bodies. 

Special  Publications -Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual 
reports,  and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket 
cards,  and  bibliographies. 

Applied  Mathematics  Series  -  Mathematical  tables,  manuals,  and  studies  of  special  interest  to 
physicists,  engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others 
engaged  in  scientific  and  technical  work. 

National  Standard  Reference  Data  Series -Provides  quantitative  data  on  the  physical  and 
chemical  properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated. 
Developed  under  a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National 
Standard  Data  Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical 
Reference  Data  (JPCRD)  is  published  bi-monthly  for  NIST  by  the  American  Chemical  Society 
(ACS)  and  the  American  Institute  of  Physics  (AlP).  Subscriptions,  reprints,  and  supplements  are 
available  from  ACS,  1155  Sixteenth  St.,  NW.,  Washington,  DC  20056. 
Building  Science  Series— Disseminates  technical  information  developed  at  the  Institute  on 
building  materials,  components,  systems,  and  whole  structures.  The  series  presents  research 
results,  test  methods,  and  performance  criteria  related  to  the  structural  and  environmental 
functions  and  the  durability  and  safety  characteristics  of  building  elements  and  systems. 
Technical  Notes— Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their 
treatment  of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or 
definitive  in  treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work 
performed  at  NIST  under  the  sponsorship  of  other  government  agencies. 
Voluntary  Product  Standards -Developed  under  procedures  published  by  the  Department  of 
Commerce  in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a 
basis  for  common  understanding  of  the  characteristics  of  the  products.  NIST  administers  this 
program  in  support  of  the  efforts  of  private-sector  standardizing  organizations. 
Consumer  Information  Series -Practical  information,  based  on  NIST  research  and  experience, 
covering  areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations 
provide  useful  background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing 
Office,  Washington,  DC  20402. 

Order  the  following  NIST  publications  -  FIPS  and  NISTIRs—from  the  National  Technical 
Information  Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB)  -  Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register 
serves  as  the  official  source  of  information  in  the  Federal  Government  regarding  standards 
issued  by  NIST  pursuant  to  the  Federal  Property  and  Administrative  Sen/ices  Act  of  1949  as 
amended.  Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717 
(38  FR  12315,  dated  May  11,  1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 
NIST  Interagency  Reports  (NISTIR)-A  special  series  of  interim  or  final  reports  on  work 
performed  by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general, 
initial  distribution  is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical 
Information  Service,  Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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